これからシステムにAPIを組み込んでいこうとした場合、まず真っ先に思いつくのがRESTful APIではないでしょうか。なんとなくは分かっているつもりでも、意外といざ実装してみると難しいのがRESTful APIです。今回はその基本的な考えを紹介します。 HTTP/HTTPSアクセス RESTful APIではHTTPまたはHTTPSアクセスが基本になります。ネットワークのプロトコルは他にもたくさんありますが、RESTfulな実装に向くのはHTTP/HTTPSになるでしょう。 HTTPメソッドがアクションを表す GETは取得、POSTは作成、PUT/PATCHは更新、DELETEは削除を表します。 パスがリソースを表す 例えば GET /users/1 であればユーザID=1に対する操作を意味します。 GET /users/1/posts であればユーザID=1の持っているポスト一覧を意味します。POST /users/1/posts であれば、ユーザID=1の新規投稿を意味すると言った具合です。 パスとHTTPメソッドを見れば、どのリソースに対して何の処理を行うかが分かるようになっています。usersはサービスやモデルの単位で設定し、その後の1という数字はサービス中のユニークなIDを示します。 クエリーで細かな条件を指定する さらにURLのクエリーを使って操作内容の細かな指定を行います。例えば一覧画面の場合、取得件数を指定するのが一般的です。その際、 GET /users/1/posts/limit/100 とはしません。 GET /users/1/posts?limit=100 とします。 データリソースの一覧を取得するという処理は決まっていますので、その詳細についてはクエリーやbodyを使って表現します。 取得するデータフォーマットを指定する RESTful APIではJSONまたはXMLでデータの送受信を行うことが多いです。その際、フォーマットの指定方法は主に2パターン考えられます。一つはパスに含める方法で、 GET /users/1.json といった具合です。もう一つはクエリで指定する方法で、 GET /users/1?format=json のように行います。 RESTfulの原則に則って開発するのはシステムの可読性を維持し、さらにメンテナンス性も良くします。パスの切り方などもRESTfulの原則に則っていれば、何の処理を行うのかも一目で分かるようになります。 簡単なルールしかないために、ついつい拡張したり、オリジナルルールを混ぜ込んだりしてしまいがちです。しかし、それをぐっと堪えて書くことで見通しの良いシステムを維持できるでしょう。

企業間におけるAPI利用が拡大していくと、API自体が利益を生み出すAPIエコノミーが広がっていきます。 APIエコノミー自体については以前記事にしています が、その中で考えるべき視点がサービスのAPI化です。 より複雑な処理をRESTfulで処理する 単純なデータベース構造やモデルの公開はRESTfulによって処理を行えます。RESTfulは開発者にとって分かりやすく、使い勝手の良いAPIフォーマットになりますが、幾つかの問題点があります。その一つがクライアント側（利用側）のコード量が増大することです。 単純なモデル操作だけをRESTfulで公開している場合、複数のモデルを連携させるような操作を実現するにはAPIを利用する側のコード量が増えがちです。例えばカレンダーに顧客との打ち合わせを追加する場合、RESTfulで考えると次のようになります。 顧客APIに対して顧客の存在確認を行う（GET） データがなければ作成を行う（POST） カレンダーAPIを使って日付が空いているか確認する（GET） 空いていれば顧客と自分の情報を合わせてスケジュールを登録する（POST） このロジックはすべてクライアント側で行わなければなりません。さらに4のスケジュール登録自体は顧客データを取得していなくても実行できてしまうため、作り手によってデータ構造が変わってきてしまう可能性があります。 サービスのAPI化を考える際には、これらの処理をある程度パックにし、一つのAPIとして公開するのが良いでしょう。必ず踏まなければならないステップがあるならば、それはクライアントではなくサーバ側で処理する方が効率的です。 RESTfulではネットワーク通信量が増える 先ほどの例においても4回のネットワーク通信が発生します。ネットワーク通信はどこでエラーが発生するか分からないため、なるべく少ない回数で終わらせる方が効果的です。システム連携が前提のAPIではコネクション数増大によるリソース欠乏にもなりやすく、その意味でもコネクション数は少ないに越したことはありません。 ネットワーク数を減らす方法として、バッチ処理で複数の処理を一回で送れるようにするものもあります。しかしこの場合、顧客の存在確認を行った上でデータの作成を判断すると言った条件処理は困難です。結局、必要なデータを集めて判定を行ってAPIをコールするというステップは変わりません。 通信を減らすための方法として、検索してデータがなければ作成して返すといったようなAPIを用意する方法が考えられます。よくある処理について一つにまとめてしまうことでクライアント側、サーバ側の処理両方を減らすことができるでしょう。 また、内部のメソッドを呼び出すのもお勧めです。この時、HTTPを経由して呼び出すのはよくありません。コネクション数が増えてしまうからです。ただしマイクロサービスによってシステムを疎結合にしている場合はうまくいかない可能性があります。 RESTfulはトランザクションに弱い RESTfulの弱点としてトランザクションがあります。業務システムにおいて途中でエラーが起こった時のロールバック処理は必ず求められるのですが、RESTfulではうまく実装するのが困難でしょう。これはHTTPの仕組み上、一回一回のコネクションで閉じてしまうと言う問題にも関係しています。 一度にデータをすべて受け取れれば、サーバ内部ではトランザクションを使った処理が可能になります。特に企業間におけるAPI活用においてはトランザクションを意識した設計が必要になるでしょう。 RESTfulというとデータベースのテーブルはモデル単位での操作が思い浮かびますが、モデルの操作だけで済むケースは多くありません。開発者がそのAPIを使って何を実装するのかを意識し、彼らにとって使いやすい形で公開する必要があります。 データベースではなく、利用する機能やサービスと言った単位でRESTfulなAPIを作ると使いやすいでしょう。

APIは一般的にプル型の技術です。クライアント側からアクセスがあるまでは待ちの状態になります。クライアント側から見ても、サーバ内部でどのデータが更新されているのかはアクセスしてみるまで分かりません。この手の問題で厄介になるのが「どのデータが削除されたのか」が確認しづらいということです。すべてのデータを見た上で、抜け落ちていれば削除されたといった確認方法であったり、処理の履歴を見て判断すると言った方法になってしまいます。 そこでサーバ側からでもデータの更新を伝えられる方法を使って、クライアントとのコミュニケーションに役立ててみましょう。 WebSocket WebSocketはHTML5仕様の一部として定義されていましたが、現在は本体とは切り離されています。WebSocketはいわゆるPubSubな形で、クライアントがサーバ側のメッセージを購読（Subscribe）します。サーバは誰が購読しているかは気にせず、発信（Publish）するだけです。とは言え、購読相手に対してきちんと届くように、または届かなくても良いと言った品質管理もできるようになっています。 HTML5の中で生まれたので仕組みとしてはWebブラウザを対象にしていますが、各種プログラミング言語向けに購読/発信できるライブラリが存在します。ws://、またはwss://（SSL/TLS版）ではじまる専用のプロトコルを利用します。 IoT分野であれば似たような仕組みにMQTTがあります。こちらはヘッダのデータ量が小さいという特徴があります。プロトコルはmqtt/mqttsといった独自のものになります。 WebRTC WebRTCはP2Pなメッセージプロトコルになります。動画や音声を流すこともできるので、動画チャットや音声チャットに使われることが多いようです。最初のコネクション情報を交換する際にはSTUNサーバを介しますが、実際のデータ送受信はP2Pにて実行されます。 基本的にクライアント同士のメッセージ送受信について行われますので、APIには向かないかも知れません。とは言え、リアルタイムにデータの送受信ができるプロトコルなので、活用法はあるでしょう。 WebHooks WebHooksはサーバに対してあらかじめURLを登録しておき、サーバ側で何かイベントがあった時に通知してもらう仕組みです。クライアントが通知して欲しいURLを登録するので、セキュリティについてはあまり考慮されることはないようです。 HTTP/HTTPSを使うので他の仕組みに比べると手軽です。ただしサーバ側の負荷は高くなる傾向があります。通知を受け取る側はインターネット上に公開されている必要があり、開発時は若干手間がかかります。 Webサイトプッシュ スマートフォンではよく知られているプッシュ通知の仕組みをWebブラウザで実現できるのがWebサイトプッシュです。まだGoogle ChromeやFirefoxなど限られたブラウザのみ実現できます。 サーバ側では対象になるWebブラウザのトークンを保持しておく必要があります。そのトークンを指定してメッセージを送信します。プログラム向けにJSONデータをPayloadとして送ることもできます。 APIをサーバ間でリアルタイムに送受信するために使うのであれば、現時点ではWebSocketまたはWebHooksを使うのが良さそうです。Webブラウザとの接続であれば、WebSocketまたはWebサイトプッシュになるでしょう。なお、リアルタイム通信系はRESTfulのようにデファクトスタンダードと言える形式が決まっていないため、サービスごとに送受信されるデータフォーマットが異なっています（それでもJSONを使うケースが多いですが）。導入する場合には一貫した設計になるように注意が必要でしょう。

マイクロサービス システムをごく小さくまとめ、APIベースで機能を提供するマイクロサービスがより広がっていくと考えられます。多くのモノリシックなシステムにおいて密結合が拡張性やメンテナンス性において負の資産となっています。マイクロサービス化することで結合ポイントを減らし、開発を容易にします。 マイクロサービスは多くがモデルデータのCRUD操作をREST APIにて提供します。HTMLを返すものは多くありません。まさにAPI向けの施策と言えるでしょう。ただし、サービスの分け方をうまくやらないと、ただシステムが細分化されただけで複雑なシステム構成になってしまいます。 最近ではマイクロサービス用のフレームワークも登場し、開発がより簡単になっています。次の段階としてはアーキテクチャであったり、サービスの切り分け方に関するソリューションが共有される年になっていくことでしょう。 Swagger 昨年できたOpenAPI InitiativeによってSwaggerは一社の情報からオープンソースへ、そして業界のデファクトスタンダードへ成長しようとしています。APIのドキュメント記法については他にも幾つかありますが、SwaggerおよびOpenAPIが最も大きなシェアを取ると思われます。 ただし現状のバージョン2と、新しいバージョン3は全く構造が変わることが決まっていますので、これまでに作成したツールは対応が迫られるでしょう。ドキュメントについてはコンバーターが用意される予定となっています。バージョン3は今年中にリリースされる予定です。 標準フォーマットができあがることで、周辺ツールも作りやすくなります。これまでにもドキュメント、モックサーバ、テストなど多くのライブラリがありましたが、さらに利用範囲が広がっていくものと思われます。 APIマネージメント 多くのAPIはサービスに紐付いて作成されます。そのため、各サービス責任者のやり方であったり、開発するタイミングでトレンドが変わっていることがあります。そうしたフォーマットの不統一感は利用者を混乱させたり、重複した開発を必要としたりします。 そういった問題を解決するためにAPIマネジメントを導入する企業が増えています。APIマネジメントを導入することでセキュリティ、負荷対策、インタフェースの統一、ログ管理などといった機能が一元管理できるようになります。 APIのインタフェースを変えるのは困難です。そのため、恒久的に使えるような明確な基準をもって設計に取り組む必要があるでしょう。APIマネジメントの多くはそうした基準をあらかじめ備えており、利用者にとって分かりやすいAPIが開発できるようになっています。 内部APIの増加 BtoBにおいては企業間のみで提供されるAPIが存在します。これらのAPIは契約した企業だけに公開されるもので、ドキュメントなども非公開になっています。しかし、多くのAPI関連ツールは公開前提に作られているものがあります。一般的なプログラミング言語においてメソッドの公開、非公開が指定できるのと同様に、APIにおいても公開、非公開が設定できるようになっていくでしょう。 内部APIの増加は企業間におけるAPIトランザクションの増加につながるので決して悪い兆候ではありません。ただし、企業が連携先を探す際にAPI情報が見つからないのは問題があるため、何らかのドキュメントは一般公開されるべきでしょう。 ハードウェア連携型APIの増加 数年前からIoTが一つのキーワードになっていますが、多くの企業がハードを買って、そこからネットワークへの繋ぎ込みを自分たちで開発しています。それらはとてもリソースのかかる作業であり、最近ではクラウドサービスと自動連携するIoTデバイスが登場しています。 デバイスがネットワークを備えている場合はMQTTまたはWebSocketのようなプロトコル、場合によってはREST APIをコールする仕組みになっています。デバイスの設定さえ行えばすぐにネットワーク上にデータが上げられるので、開発がとても効率化します。 IoT向けにクラウドサービスを開発している企業においては、デバイス企業と組んだ上でサービスの提供が求められていくでしょう。 HTTPエラー表現の統一 2016年03月に出た RFC 7807 - Problem Details for HTTP APIs が参考になります。この中ではapplication/problem+json または application/problem+xml というレスポンスヘッダーが提案されています。これまでREST APIではHTTPステータスを使ってエラー表現を行ったり、独自のエラーオブジェクトを返したりしていましたが、これを統一していこうという動きです。 返却する内容ですが、例えばJSONの場合は次のようになります。 { "type": "https://example.com/probs/out-of-credit", "title": "You do not have enough credit.", "detail": "Your current balance is 30, but that costs 50.", "instance": "/account/12345/msgs/abc", "balance": 30, "accounts": [ "/account/12345", "/account/67890" ] } こうしたJSONとHTTPステータスを合わせてエラーを表現していきます。 企業におけるAPI利用、公開が徐々に進んできています。2017年もまた、提携であったり自社システム同士の連携にAPIを利用すると言ったケースも増えていくことでしょう。

最近のAPIではJSONをリクエスト/レスポンスフォーマットとして採用することが多いですが、サイズが決して小さくないことやパースにかかる時間などを気にするケースもあります。そこで考えてみたいのがシリアラズされたフォーマットであったり、他のフォーマットです。今回はそんなフォーマット例を紹介します。 JSON RESTful APIで最も多いファイルフォーマットではないかと思います。JavaScriptのオブジェクトフォーマットですが、多くのプログラミング言語でパースしたり、生成できるようになっています。それだけシンプルなフォーマットであると言えます。 冗長性はあまりありませんが、JavaScript特有の波かっこの多さやダブルクォートに囲みなどはあまり好まれない部分と言えます。 google/protobuf: Protocol Buffers - Google's data interchange format Googleが開発しているフォーマットです。XMLより3〜10倍小さく、パースは20〜100倍高速であるとしています。あらかじめプロトコル定義ファイルを作成し、コンパイルすることで多くのプログラミング言語に対応したコードが生成されます。 MessagePack: It's like JSON. but fast and small. JSONと似ているわけではありませんが、サイズについては対JSONとして強く意識しているようです。JSONから不要な部分を削り取ったことで、サイズは大幅に減っています。対応しているライブラリも多いのですが、人による可読性が低いのが難点と言えるかも知れません。 Welcome to Apache Avro! Java、Python、C、C++、C#などで使えるデータのシリアラズフォーマットになります。プログラミング言語が限られてしまいますが、エンタープライズな企業システムであれば採用できる可能性がありそうです。スキーマはJSONで定義します。 The Official YAML Web Site 人が読みやすいという点を重視したフォーマットです。非常に多くのプログラミング言語でサポートされていますが、APIのフォーマットよりも設定ファイルのフォーマットとして採用されることが多いようです。 Extensible Markup Language - Wikipedia いわゆるXMLのことです。Webサービスの頃に最も使われたフォーマットです。閉じタグで囲むというのが冗長的で面倒というのが悩みのタネでした。企業間でも使えるように検証する仕組みなどもあらかじめ用意されている点が利点です。 多くの場合、XMLを解釈するライブラリはそのコードが独特なものになりがちです。JSONのようにハッシュや連想配列、Dictionaryになるわけではありません。 シリアラズされたフォーマットは人が読むことはほぼ想定されていません。そのためプログラミング言語同士の中でしか使われませんがサイズが小さかったり、高速に処理ができるようになります。サービスの規模や利用想定によって採用を考えてみても良いでしょう。

これまでサポートや問い合わせに寄せられるメッセージは人の目で見て、その意味を解釈した上でデータベースに構造化して登録されていました。しかし何百、何千とある文章を読むのは大変なことです。 それらを機械で処理できる可能性を持っているのが自然言語分析です。機械学習モデルをベースにすることでテキストの構造はもちろん、意味も分析できるようになってきています。 Cloud Natural Language API  |  Google Cloud Platform Googleが提供する自然言語分析APIです。非構造化テキストの中から場所や人の情報を取り出したり、感情を抽出することもできます。他のAPIと合わせることで音声データを分析したり、手書き文書からデータを読み取ることもできます。 IBM - Natural Language Classifier 自然言語分類 | Watson Developer Cloud - Japan IBMが提供する自然言語分類APIです。テキストの背後にある意図を解釈し、あらかじめ用意しているカテゴリのどれにマッチするのかを分類分けできます。クラスタリングの高性能版と言えます。 解説・事例 | docomo Developer support | NTTドコモ RESTfulにテキスト情報を分類分けできます。そしてもう一つ一般的にセンシティブと呼ばれる言葉を分析し、テキスト内容が危険の高いカテゴリにどれくらい近いかを分析できます。 テキスト分析 - Cognitive Services | Microsoft Azure Azureで提供される言語処理APIです。英語のテキストを分析し、自社ブランドに対する評価を判断できます。さらに重要なフレーズを抽出したり、トピック検出、言語判定が可能です。 Conversational User Experience Platform for products and services - API.AI 与えられたテキストからアクション、名前、人、日付などをJSONで取得できます。それによってテキストが何を目的としているかが判断できるようになります。英語のみサポートしています。 非構造化テキストから意味を見いだすというのはとても困難です。テキストを分析する分かち書きのような処理は分類分けはできますが、その奥にある意図までは読み取れませんでした。自然言語分析APIを使うことでメールやチャットなどのテキストも自動的に分析し、適切な対応が行えるようになるでしょう。

データを可視化する方法としてグラフやチャートが用いられます。ユーザにとってはメリットがある反面、開発者としてはグラフを出力するのはそう簡単ではありません。画像ライブラリを入れたり、JavaScriptのグラフライブラリに合わせたデータ出力が求められます。 そこで今回はグラフを簡単に作成できるAPIベースのグラフサービスを紹介します。 Charts  |  Google Developers Googleの提供するグラフサービスGoogle Chartsです。カスタマイズも容易で、グラフは画像の他SVGでの出力もできます。刻々と更新されるデータに合わせたリアルタイムグラフも作成できます。 Charts  |  Google Developers HeartRails Graph | キュートな円グラフ簡単作成サービス HeartRailsが提供する円グラフ作成サービスです。項目と割合を設定するだけでグラフが作成できます。べつやくメソッドと呼ばれるグラフを模しており、フォントも可愛らしいものが採用されています。 HeartRails Graph | キュートな円グラフ簡単作成サービス rurihabachi.com - Web API - Function(x) Graph 関数グラフを描くためのサービスです。実データではなく、関数を与えるとグラフが表示されます。 rurihabachi.com - Web API - Function(x) Graph ChartBlocks Charting API データセットを適用してグラフを生成します。グラフはSVG/PNG/JPEG/PDFといったフォーマットで出力できます。データのアップロード（リアルタイムデータ含め）、グラフのカスタマイズもAPI経由でできます。 ChartBlocks Charting API APIを使うことでサーバ側でライブラリをインストールしたり、JavaScriptで処理すると言ったコードが不要になります。手元にデータがあるならばこれらのAPIを使えばすぐにビジュアル化が実現するでしょう。

APIは外部リソースからデータを取得して他のデータと合わせて自分たちのサービスに付加価値を追加できますが、同じように外部からデータを取得する手法としてスクレイピングが知られています。今回はスクレイピングとAPIの違いを紹介します。 スクレイピングとは？ スクレイピングはサーバサイドのプログラミング言語を使って外部サーバへアクセスし、そのコンテンツから自分たちの欲しい情報を引き出す手法です。多くはHTMLを返す場合に使われ、DOMを解析したり正規表現を使ってデータを抜き出します。 スクレイピングはサービスが認めていない方法 APIはサービス提供側が一定の条件を設けた上で公開している開発者向けの機能になります。対してスクレイピングは本来はユーザ向けであるHTMLコンテンツをコンピュータに解析されるもので、公式にサポートされているものではありません。 そのためコンピュータによって負荷を高めたり、許容されていないアクセスを行うと不正アクセス防止法違反によって処罰される可能性もあります。 なぜスクレイピングをするのか 最も大きな理由としてアクセス先のサービスがAPIを提供していないという問題があります。APIがあるならばそれを使いたいと考えるでしょうが、APIがないためにスクレイピングに頼らざるを得ないと言えるでしょう。また、APIが公開されていたとしても必要な情報がスクレイピングしなければ取得できないと言ったケースもあります。 コンテンツは企業にとって生命線である場合も多く、それらのデータをまとめて抜かれてデータベース化されることを懸念する声もあります。 スクレイピングのデメリット スクレイピングはHTMLコンテンツの形式に左右されます。そのためデザインが変わるとデータがうまく取れなくなる可能性があります。その場合、再度スクレイピングの作成し直しになりますが、大幅にデザインが変わったりURLの階層が変わったりするケースもあります（実際にはSEOへの影響があるのでURLは変わらないことのが多いでしょう）。 また、サービス提供側でログを解析している場合、怪しい動きをするログを確認するとアクセス拒否される可能性があります。Googleなどシステムが強固なサービスはすぐに弾かれる可能性があり、その結果としてスクレイピング以外でのサービス利用においても影響を受けることになります。 さらに認証後のデータを取得するようなスクレイピングはサーバ側にID、パスワードなどを保存しなければなりません。これは利用者にとって大きなセキュリティリスクになることでしょう。 スクレイピングを防止するには スクレイピングはAPIが提供されていれば防げる行為です。スクレイピングは、それをしなければならないほど、コンテンツに魅力があるという証拠とも言えます。であれば公式としてきちんとアクセスコントロールした上でコンテンツをAPI提供する方が健全と言えるのではないでしょうか。 スクレイピングはイタチごっこになりがちで、防げるものではありません。そして開発者の不用意なコードによってサービス提供側が影響を受けたり、サービス利用者が迷惑を被ることになるでしょう。そうならないためにAPIを公開するというのは大切なことです。 スクレイピングの例 最近ではアプリやWebサービスで自分の資産管理を行う系統のサービスにおいて、各金融機関、クレジットカードのサイトへスクレイピングを行っているケースがあります。金融機関のID、パスワードを登録しなければならず、万一漏洩などが起こった時には大きな損害につながる可能性があります。 理想的には各金融機関がOAuth2ベースのAPIを公開し、適切なアクセスコントロールを実現できる仕組みを用意するのが一番でしょう。

多くのAPIが認証情報とともに実行されます。実行ユーザを特定する目的の場合もあれば、APIキーのような情報を使ってコール数をカウントする目的で使うこともあります。 今回はそんなAPIにおける認証情報をAPI中のどこに持たせるのが良いか、紹介します。 URLパラメータ URLのパラメータとして持たせる場合はセッションキーやトークン文字列であることが多いです。もう一つのパラメータ（アプリケーションキーなど）と合わせて、認証が正しいことを検証するようになっています。 トークン文字列は一定期間で切れる仕組みになっており、有効期限が過ぎた後はリフレッシュして新しいトークン文字列を取得し直します。 URLの場合、Webブラウザからの検証がしやすいのがメリットです。単純にURLをブラウザで開いて結果が返ってくればパラメータが正しいかどうかが確認できます。 HTTPヘッダー HTTPヘッダーに認証キーを埋め込む方法もよく見られます。Webブラウザからの確認は若干難しくなりますが、Ajaxのような仕組みを使えばヘッダーに文字列は簡単に追加できます。 クエリー文字列はどういった操作を行うか指定するものとし、ヘッダーは認証などシステムのスコープを分けるのは開発者にとって分かりやすい区分けかも知れません。 セッション、クッキー あまりお勧めしませんがセッションやクッキーに認証情報を持たせることがあります。スマートフォンアプリなどで、非公開な自社アプリ限定で使っているAPIの場合、このようなケースがあります。 利点としては既存のWebサービスと同じ仕組みで使いまわせるという点が挙げられます。Webサービスでは認証情報をURLに載せたりしません。ヘッダーにするとWebブラウザからは利用できなくなります。 WebサービスとAPIは分けて提供する方が良いのですが、Webサービス側で認証を通っているにも関わらずAPI側の認証が通っていないと判断されるのはユーザビリティが良くありません。そのため、セッションキーを利用するケースも少なからず存在します。 お勧めな方法は？ OAuth2ではURLに認証トークンを追加する方法になっています。実装としては一番手軽と言えるかも知れません。次にヘッダーへの追加が良いでしょう。セッションを用いるのはよほどのことがない限り避けるのが良いでしょう。 Webサービスとの連携についていえば、セッションの認証キーとAPIの認証トークンとを交換するAPIを用意するのが良さそうです。まず、そこにアクセスすることでAPIアクセスに使える認証トークンが手に入ります。その後からのアクセスは認証トークンを使えば良いのです。認証トークンはオンメモリに保存し、別なURLに移動した際には再度交換すれば良いでしょう。認証トークンは重要な情報なのでlocalStorageに保存するのは避けた方が良いでしょう。 認証トークンは定期的にアップデートしましょう 認証トークンは1週間程度の有効期限が良いかと思います。多くのスマートフォンアプリでは認証トークンをアプリ内にストアし、それを使い続けます。しかし万一認証トークンが漏洩した場合、誰でもそのサービスへなりすましでアクセスできるようになってしまいます。 認証トークンをアプリ内にストアするのは致し方ありませんが、アプリの起動時に新しいものと差し替えても良いでしょう。そして認証トークンは複数の端末からは使えないように制御するのが良いでしょう。そのため1ユーザに対して複数の認証トークンが保存できるようになっているのがお勧めです。 APIにおける認証トークンは認証情報そのものです。漏洩すると、APIを経由してデータ操作が自由にできるようになってしまいます。それだけに漏洩しづらい場所に保存したり、使い方にも注意が必要でしょう。 どのアプリ、どのブラウザまたはシステムからアクセスしたかが分かるように、認証トークンは複数発行できるようにしましょう。そうしてユーザから任意のタイミングでトークンを削除したり、再生成し直せるようになっていると便利ではないでしょうか。

Webブラウザは常にセキュリティ、ユーザへの安全なインターネット提供を前提に作られています。そのため外部リソースを組み合わせて使うAPIとは相性が悪いことがあります。iOSやAndroidといったスマートフォンアプリやサーバサイドのプログラミング言語では当たり前のようにできることがWebブラウザではできないのです。 今回はAPI利用時に注意したいJavaScriptによる外部リソース取得方法について紹介します。 JSONP HTML4の時代において、JavaScriptから外部リソースを取得する方法は限られていました。そこで考えられたのがJSONPと呼ばれる方法です。動的にJavaScriptタグを生成し、その中でリクエスト時に指定した関数名で処理を呼び出してもらいます。そしてその関数の引数としてAPIで渡したいデータをJSON形式で指定します。 JSONPは大いに利用されてきましたが、問題点はスクリプトタグを出力するという関係上、GET処理しかできませんでした。そのためデータを作成、更新、削除するような使い方に対して提供すると悪意のあるデータ操作を可能にしてしまう危険性があります。 プロキシ 内部で立てたサーバに対してアクセスを代行してもらうプロキシ方式もよく使われました。この方法の場合、同一ドメインであればJavaScript側からもPOST/PUT/DELETEアクセスができます。そしてその内容をサーバ側がAPIにそのままリクエストしてレスポンスを返すのです。 問題点としてはサーバを用意したり、プロキシアクセスするコードを書かなければならない点と、プロキシアクセスの場合、認証情報が渡しづらいということが挙げられます。多くの場合、匿名アクセスできるサービスであったり、特定のアクセスキーを使うようなサービスで使われています。 CORS HTML5の時代になって使われるようになったのがCORSです。クライアントからOPTIONSヘッダーでリクエストし、それに対してサーバがアクセスを許可するかどうかを返します。その結果によってWebブラウザ側がデータ取得を許可します。 この方法は現在広く使われており、APIアクセスの他、Canvasに描画する画像リソースのアクセス権限についてもCORSで制御できます。 CORSはアクセス元のドメインで単位で、どのメソッドを許可するかを指定できます。ただし、ここで制御したとしてもスマートフォンアプリやサーバサイドのスクリプトからのアクセスは制御できませんのでご注意ください。 iframe iframeを動的に生成し、親フレームと子フレームでpostMessageを使ってデータの送受信を行う方法があります。子フレーム側のコンテンツでもpostMessageを使う必要があるので、JSONを単純に取ってくると言うほど簡単ではありません。 例えばFacebookのFBアプリはコンテンツの高さを動的に変更できます。これは子フレーム側に組み込まれたFacebook SDKがコンテンツの高さを親フレームにpostMessageで投げ、親フレーム側でiframeのサイズを変更しています。若干APIに比べるとトリッキーな実装になるでしょう。 HTML5でXMLHttpRequest2になり、CORSが使えるようになりました。が、HTML5に対応していないブラウザでは使えない技術なので、レガシーなブラウザをサポートする場合は別な技術と組み合わせる必要がありそうです。 クロスドメインによるアクセスはJavaScriptで常に問題になりますので、APIを利用する際はもちろん、提供する際にも注意してください。不用意にすべてを開放するのではなく、設定で利用できるドメインを制限すると言った仕組みを提供するのも良いかと思います。

APIを使ったシステム開発で常に問題になるのがレスポンスです。一つ一つのレスポンスは高速であったとしても、リクエスト数が増えればトータルのレスポンスが遅くなっていきます。 今回はAPIのレスポンスを最適化するためにできる改善案について紹介します。 処理の並列化 10回のリクエストを順番に行なっている場合、前の処理が終わるまで次の処理ができません。一つでもレスポンスが遅い処理があると、それがボトルネックになって全体が遅くなります。それを防ぐのが並列化です。 JavaScriptなどはネットワーク処理が並列で行えます。プログラミング上の注意点はありますが、複数のネットワークリクエストを並列で行えば一番重たい処理が終わった段階で全ての処理が終わってるでしょう。他のプログラミング言語でもスレッド処理を使うことで並列処理が行えるようになります。 問題点としては1つの処理結果を受けて別な処理を行う場合に向かないことです。なるべく分岐処理が入らない形で一気にデータの投入や更新を行うようにすべきでしょう。もう一つの問題は多数のリクエストが同時に走ることでサーバの負荷が上がってしまうことです。サーバによっては同じリクエスト元からの大量のアクセスがあるとDoS攻撃と見なしてリクエストを破棄してしまうことがあります。 キャッシュ クライアント側で処理をキャッシュするのも一つの手です。メモリ上に乗せるのはもちろんのこと、クライアント上のストレージ上に保存しておくようにすれば再実行した際にもデータを取得せずに済むようになります。簡易的にはKVSのようなキーと値だけの保存形式から、SQLiteなどを使ったデータベースまで考えられます。 問題点はデータの状態が最新であるかどうかの確認する手段を用意しなければならないということです。特にサーバ側で削除されたデータがあるかどうかの確認が問題になりがちです。 データをまとめて返す（画面最適化） スマートフォンアプリでよくある方法ですが、必要なデータをまとめて返してしまうことでネットワークリクエスト数を削減できます。専用のAPIを用意することで、ほぼその画面を作るためだけのAPIとして最適化されます。多くのスマートフォンアプリでは専用の非公開APIを用いて開発されているため、このような方法が使えます。なお、画面の変更に伴ってAPIの形式も変化しますが、後方互換性を維持する必要があるためAPIのレスポンスが徐々に肥大化する傾向があります。 データをまとめて返す（バッチ処理） また、ゲームアプリなどで使われている方法で、複数のAPIアクセスをバッチ処理として一つのリクエストに集約するというものがあります。これは主に取得系APIに対して用いられます。一つ一つはRESTfulなAPIですが、まとめてアクセスすることで一度に複数のデータが取得できます。 これは実装も楽で、プロキシサーバを立てるだけで済みます。プロキシサーバが複数のAPIアクセスを個別に行い、レスポンスをまとめて返却します。この方法は簡易的な一方、重たいAPIアクセスがあるとボトルネックになって結果が返るのが遅くなる傾向があります。 GraphQLを使う GraphQLがベストかは分かりませんが、原理的にはクライアント側から自分が必要なデータを指定するという方法になります。つまり必要なデータしか取得しないことでデータベース側の負荷を下げたり、転送量を小さくできます。また、画面最適化のようにクライアント側のバージョンアップに伴う後方互換性を気にする必要がありません。 問題点としてはGraphQL自体がまだまだ新しい技術であるため、GraphQLのAPIが変わる可能性があることや、クライアント側で自由にデータ取得方法が指定できるために、サーバ側の最適化が行いづらいという問題があります。元々APIはレスポンスを含めてサーバ側でコントロールしてきましたが、GraphQLでは逆になります。利点とも言えますが、開発者がその場その場の最適解を選ぶと、全体としてはアンバランスになるのは良くあることです。 もちろん、アプリケーションサーバを改善したり、データベースの構造やインデックスを見直すというのは行わなければなりません。しかしAPIサーバだけを見るのではなく、クライアント側でもできることも多数あるでしょう。提供側と利用側双方で改善し、ユーザに快適なサービスを提供するようにしましょう。

Swaggerをベースとして策定が進んでいるOpenAPI Specification 3.0ですが、その内容がブログ記事になっていました。 大きく分けて6つの点が課題として掲げられています。 1. 構造の改善 Swaggerでは粒度が異なる状態で混在していた構造について、大きく変更されています。以下は TDC: Structural Improvements: explaining the 3.0 spec, part 2 | Open API Initiative にて紹介されていた画像です。 via TDC: Structural Improvements: explaining the 3.0 spec, part 2 | Open API Initiative definitions/parameters/responses/produces/consumesといったオブジェクトがなくなり、すべてcomponentsに統合または廃止されるようです。結果として構造はとてもすっきりしています。 2. バージョン定義の変更 これまでは 2.0 という書き方でしたが、今後は 3.0.0 のようにパッチバージョンを含むようになります。バージョン番号は セマンティック バージョニング 2.0.0 - Semantic Versioning に則った形で管理されます。 3. Components 上記画像でもありますが、Componentsというオブジェクトが追加されます。2.0では幾つかのプロパティがグローバルに適用されていたり、スコープに矛盾が見られました。そこでComponentsでは再利用されるメタデータだけをまとめて管理するようになります。 4. マルチホスト Swaggerではhostは一つしか存在できません。3.0ではhostsとなり、複数ホストを管理できるようになります。それぞれベースパスやスキーマも格納されるようになります。さらにpathの中でhostを定義して上書きもできるとのことです。 5. 他の記述オプション これまではオペレーションレベルで書かれていたのが、今後はリソース指向で作られるようになります。リソース指向では GET a foo 、 POST a foo 、 DELETE a foo といった具合にリソース（foo）に対して何かするといった具合に読めるものです。パスの説明では短い説明文と長い説明文を使えるようになります。 6. レスポンス例の拡張 これまではJSONまたはYAMLでのみ記述できましたが、これが大幅に拡張されます。JSONを使って任意のフォーマットで記述できるとのことで、 $ref プロパティを使って外部ファイルを参照するようにもできます。 基本的には構造が変わるとのことで、これに合わせてSwagger用のツールも変更が求められるでしょう。構造的には分かりづらい部分も多かったので、3.0によって全体の見通しが良くなったように感じられます。リリースはまだですが、 OAI/OpenAPI-Specification: The OpenAPI Specification Repository にてディスカッション内容は見られるようになっています。 via TDC: Structural Improvements: explaining the 3.0 spec, part 2 | Open API Initiative

昨今人気を集めているGo言語ですが、メリットとして以下の点が挙げられます。 ビルド後の実行速度が速い 環境構築のスピードが速い バージョン依存の問題が少ない 環境依存の問題が少ない ポータル性がよい 逆にデメリットとしては以下の点も良く挙げられます。 JSON、XMLなどの扱いにも厳密な構造体が必要になる 冗長的になりがちな戻り値のエラーチェック デバッガや、Loggerなどが充実していない 開発時・運用時のノウハウ・ナレッジが、まだまだ少ない そんな中、上記のデメリットをカバーするためにGoによるマイクロサービスフレームワークの存在があります。今回はGo製のマイクロサービスのフレームワークやツールキットをご紹介します。 goa :: Design-first API Generation デザインファーストを謳うGO製マイクロサービスフレームワークです。デザインコード (goa API Design Language) のファイルを作成するだけで、マイクロサービスのコアとなるファイルを生成してくれます。 goa API Design Language を改めて学習する必要がありますが、API開発を一度でも行っていれば学習コストは高くないでしょう。 開発サイクルはgoa DSLに沿ってAPIをデザインし、 goagen コマンドにより構造体やバリデーションコード、ハンドラを生成するという流れです。 goa DSL は、カスタムDSLを作成することも可能です。 go-kit/kit: A standard library for microservices. Go Kitは分散プログラミング用のツールキットです。マイクロサービスや大規模サービスを構築するために、既存のライブラリの隙間を埋めることができ、ビジネスロジックに集中できるとあります。後述するマイクロサービスフレームワークのGizmoや、Go-Microなどでも利用されています。 NYTimes/gizmo: A Microservice Toolkit from The New York Times gizmoは『Newyork Times』が開発したマイクロサービスフレームワークです。大きく4つのパッケージにより構成されています。 config パッケージ アプリケーション設定用のパッケージです。 server パッケージ ルータとサービスなどのサーバパッケージです。 web パッケージ HTTP向けのパッケージです。 pubsubパッケージ メッセージキュー向けのパッケージです。 フレームワークの概要は Introducing Gizmo - The New York Times で紹介されています。 ※ ライセンスはApache 2.0 をベースに、著作権はThe New York Times Company（ニューヨークタイムズ社）となっています。 Go Micro Microはマイクロサービスのツールキットとして、各サーバ/サービスツールをそれぞれ分割して別々にパッケージされたものです。中核となる go-micro 、Webサービスを展開するための go-web 、モニタリングツールの monitor-web 、サービスをトレースするための trace-web など、マイクロサービスを構築および運用するためのパッケージが揃っています。一通り思想から理解しなければ使いこなすのが難しそうですが、Microで統一することで必要な機能が揃うので統一感のある開発ができるでしょう。 The Micro Blog - Simplifying building and managing microservices に、Microの概要がありますのでぜひご覧ください（英語）。 Micro - A microservice ecosystem. Simplifying building and managing distributed systems. では、モニタリング系ツールのデモも試せます。 koding/kite: Micro-service framework in Go KiteはGo言語による分散システムを簡単に書けるようにしたRPCライブラリです。大きな特徴としては、サービス側のURLを知っていれば直接接続でき、URLがない場合はKONTROLと呼ばれるサービス発見メカニズムを利用して接続できるようになっています。接続認証にはJWTが採用されています。 ブログで解りやすく紹介された記事 があります。 なぜGo言語でマイクロサービスを開発するのか？ 今回は4つのフレームワークをご紹介しましたが、そもそもなぜGo言語がマイクロサービスに向いているのでしょうか？ マルチスレッドのコーディングが楽である Go言語は安全にマルチスレッドコーディングが書ける言語です。他の言語と比べた場合のパフォーマンスなどは特筆すべきものがあります。もし、API開発において大量のPOSTデータやマルチスレッドなバックエンドの処理する必要がある場合には、その威力を発揮するでしょう。 ポータビリティに優れる Go言語はポータル性に優れた言語です。例えば運用後にサーバを移設したいケースでは、特定のサーバ環境にシステムがロックオンされてしまい、思わぬ追加開発が行われることになりかねません。APIシステムは息の長いシステムになります。開発後の運用を考えると、ポータビリティに優れるGo言語は良い選択肢となります。 言語特有の縛りがある 言語の縛りがあることはAPI開発後の運用において、最大のメリットとなるでしょう。 一部でGo言語はコード記述方法が退化していると表現されています。しかし、この言語の縛りがあるがゆえに継続的なメンテナンスや開発者が変わる度にコードの癖が変わったりせず、運用保守できるようになります。 Go言語自体も採用事例も多くなり、日本語の情報も充実しつつあります。現在、Go製のマイクロサービスも日々進化を続けています。実装の敷居も低いため、プロジェクト初期の開発におけるモックアップ制作のスピードにおいてもGo言語は有力な開発言語となるでしょう。 ぜひ今回紹介したマイクロサービスフレームワークを利用し、スピード感ある開発を行ってください。

AWS Lambdaを使えばサーバレスでシステム構築ができます。最近ではそうしたサーバレスなシステムをサーバレスアーキテクチャとして人気があります。今回はそんなサーバレスアーキテクチャを実現するためのサービスを紹介します。 AWS Lambda (サーバーレスでコードを実行・自動管理) | AWS 最も有名なのがAWS Lambdaでしょう。1ヶ月100万回までのリクエストが無料で、その後も低料金で処理ができます。Java、Node.js、Pythonがサポートされています。 Functions | Microsoft Azure Microsoft AzureでもLambdaと同等のサービスが提供されています。無料枠も月100万回リクエストと同じように設定しています。利用できる言語は幅広く、C#、Python、Node.js、PHPなどの他、Bash、Batch、PowerShellでスクリプトの作成ができます。 Webtask Node.jsで書いたコードをそのまま実行できます。無料から利用できますが、月9ドルまたはカスタマイズの料金プランが用意されています。 webscript - scripting on the web サーバサイドで動かすコードがLuaなのが特徴です。スケジュール実行がサポートされているので、Cronの代わりに使うと言ったこともできます。 hook.io サポートしている言語はJavaScript/Python/PHP/Bash/Luaと多数あります。カスタムドメイン、Cronなどとなっており、機能が多いのが特徴です。 nstack - algebraic infrastructure Pythonをサポートしています。ごく小さなコードを書いて、後は専用のコマンドを使ってWebサービス上にデプロイできます。 Breadboard.io GitHub上にあるコードをそのままサーバサイドで実行できるのが特徴です。データベースはMongoDB、メールやSMS送信、画像変換といったライブラリが利用できます。利用できる言語はNode.jsに限定されています。 いかがでしょうか。多くの場合、Node.jsを使っています。そして、各サービスの特徴に合わせてプログラミング言語が追加されているようです。また、多くはオープンソースとしてプラットフォームを公開しており、ローカルや開発環境下ではオープンソース版で試し、本番環境はクラウドサービスを使うと言った具合に使い分けられるようになっています。 サーバレスアーキテクチャをうまく使うとサーバリソースの低減やメンテナンスコスト削減に繋がります。ぜひシステムに合わせた利用法を考えてみてください。

10月13日に Enterprise APIs Hack-Night #7 が開催されました。今回はMarTech（マーケティング×テクノロジー）をテーマに行われました。マーケティング分野はテクノロジーの発展がめざましく、マーケティングオートメーションなどのキーワードにも注目が集まっています。 この記事では各登壇内容について紹介します。 APIでつながるマーケティングの実現 株式会社シャノン 技術統括本部 取締役 堀 譲治 さま 資料はこちら シャノンではマーケティングプラットフォーム、マーケティングオートメーションツールを開発しています。システムのコンセプトとして、マーケティングに必要なものを一切提供します。メール配信、セミナー管理、テレマーケティング、ダイレクトメールなどなど。マーケティングオートメーションが最近ホットで、海外からも色々入ってきています。シャノンではオフラインでの名刺情報管理やセミナー、イベント管理などの機能が実装されているのが特徴です。オフライン、オンラインの両方をサポートしています。 そして我々のシステムではAPIが提供されています。 なぜAPIを開発したのか？ 2009年（製品をリリースして3年目）がAPI提供の最初の年になります。増え続ける要望に対して開発リソースが足りていませんでした。それらの開発を外部開発パートナーにお願いしたいとは思いつつも、顧客ごとにコードを変えてカスタマイズするのは長期的に見た時に難しいと考えました。そこでAPIを開発することを決めた次第です。 つまり必要に迫られてAPI開発をスタートしたというのが本音です。 APIがあることのメーカーとしてのメリット APIによってユーザがベンダーロックインを回避できるようになりました。APIがなかったら、製品を買ったら最後、交換ができません。また、APIがあることで追加開発ができるようになりました。APIによる先進性のイメージもメリットです。今は薄れていますが、当時ベンチャーで最初からAPIを提供しているケースは多くありませんでした。 そしてソリューションの大規模化が挙げられます。APIがあることでCRMやCSRとの連携など、マーケティング全体を考えた提案、営業ができるようになりました。最初は物売りでしたが、APIによってソリューション系ベンダーになったと言えます。それに応じて開発パートナーなども増えてきました。 さらに自社の中でマイクロサービス化が可能になりました。自社の中でもAPIを使うことで、一つのサービスが小さなサービスの集合体として作れるようになりました。 APIの種類 現在2種類のAPIを提供しています。バックエンド用APIはXMLで、認証があります。主にサーバ間連携に使われています。もう一つはフロントエンド用で、対象はJavaScriptとなっています。こちらは認証不要でハイパフォーマンスなものです。フォーマットはJSONを使っています。 API提供者としての苦労 大きな問題としてはリソース制限があります。現状ではハードな制限ではなく紳士協定でやっています。その上でサーバリソースを見ながら調整したり、アラートが出たらクライアントに連絡して調整してもらいます。APIインタフェースの変更は基本的に行いませんが、実際の利用状況を見ながら変更したり廃止も行っています。APIのバージョニングは今のところ行っていません。 APIを公開しただけでは使ってもらえません。そのための布教活動も必要です。事例も必要なので、まず数社に狭く深く使ってもらう必要があります。さらに自社でも積極的に使って、問題があればAPIを変更して使い勝手を高めています。 APIの活用事例 今回は以下の事例を紹介します。 - 名刺アプリ - 独自の管理画面構築 権限によって変えたり、大規模イベントの時に利用することが多いです。 - 展示会での一括資料請求フォーム 一社ごとではなくチェックボックスでまとめてできます。 今後 マーケティングにおける統合管理が重要になってきます。例えばWebは頑張っているんだけど、セミナーや電話、代理店は半端…といったことはよくあります。WebはKPIがとりやすいですが、他の施策は人力なところもあり、なかなか管理しきれていません。 2011年時点でマーケティングベンダーは150社くらいでしたが、2016年では3,500にものぼっています。マーケティングオートメーションだけで100社以上あります。今後も増えていくかも知れません。それはなぜかというと、マーケティングの施策が増えているからです。昔はテレビ、新聞とかだけだったのが、今は膨大に増えています。それらを正しく判断して予算配分するのはとても難しいのが実情で、マーケティングオートメーションの活かせる道だと考えています。 API利用開発のTIPSご紹介 株式会社アクティブ・ワーク　Cross Device Solution Assistant Leader 吉田 晴樹 さま SMP APIを利用した開発事例紹介 生命保険会社のバースデーメール開発を紹介します。生命保険会社の顧客の赤ちゃんに対してメールを送るというものです。元々同じ仕組みはありましたが、普通にメールを送るだけで味気ないものでした。そこでFacebookコネクトを通じてスライドショーを表示するようにしました。 これはAPIを使っているので、顧客のメールアドレスを持たずにサービスが提供できるというものです。 WebフレームワークとAPI ここからは開発者の視点でお話していきます。 SPA（シングルページアプリケーション）ではない、従来のWebシステムの場合は一覧、詳細画面と一回一回通信を行います。対してSPAは一回にすべて取得して表示は隠しておきます。そして必要に応じて表示を切り替えます。主なフレームワークとしてはAngularJSやReactがあります。 SPAではフロントエンド側でデータやビジネスロジックを殆ど持たせられません。そのため非同期でサーバと通信を行ってデータ取得を行います。つまりAPI利用が前提になっています。そして、その際にはREST APIを使って開発することが増えています。 例えばAngularJSの$resourceライブラリはREST APIが使いやすくなるライブラリです。これを使うことでAPIを扱う部分のコード量が数分の一になってしまいます。 開発者を支えるMcokAPI さらに必要なのがMockAPIです。API提供元でもサンドボックスを用意してくれていますが、あまり勝手に叩くわけにもいきません。さらにAPIがまだない場合もあります。他にもエラーパターンを色々試したい、実行速度を落としてAPIを試したい時もあります。こういうときに便利なのがMockAPIです。 MockAPIとはAPIのように動くサービスで、ダミーのレスポンスを簡単に得られるようになります。例えばeasymock、stubby4nodeなどがあります。stubby4nodeは機能がリッチですが、設定がちょっと面倒です。 他にもAmazon API Gatewayを使う手もあります。画面から簡単にAPIを定義できて、モック用のAPIを作るのに使えます。 Q. Angularを採用した理由 スマートフォン用にリッチなUIで見せたいと言った時に使えます。 Q. お客さんからAPIを使って作りたいと言った要望が来ますか？ APIを持っている会社さんから要望が来ることが多いです。 APIを利用したMautic（マーケティング・オートメーションツール）と他システムとの連携について ANNAI株式会社　Principal Software Engineer 青山 義万 さま 資料はこちら Mauticは世界初のオープンソースのMA（マーケティングオートメーション）ソフトウェアになります。日本語を含む52言語に対応しています。8万以上の企業で導入されており、1日250社くらい導入が増えています。 他の商用システムとの違いとしては、 - カスタマイズができる - オンプレミスでも運用できる - セットアップ、トレーニングフィーが無料 - コンタクトのデータに応じた従量課金がない といった点になります。他にもMautic Cloudがあります。フリーとプロがあって、サインアップから5分程度で利用可能です。 動作環境はLAMPスタックで、ライセンスはGPL v3になっています。ソースコードはGitHubで公開されており、日本人はコントリビュータが3名くらいといった規模です。最新リリースの2.1が2016/08で、3ヶ月に一回くらい大きなリリースが行われています。 2015年末くらいから日本語リソースが充実してきました。現在、翻訳はほぼ100%となっています。東京、名古屋、札幌でミートアップイベントをやっています。他にもSlackの日本語チャンネル、日本語フォーラムが立ち上がっています。 Mauticによって、誰でもすぐにマーケティングオートメーションがはじめられるようになりました。 MauticとAPI Mauticでは以下のAPIを提供しています。 - REST API - Webhook - Plugin REST APIではOAuth2で認証してユーザ権限に対応したアクセス制御が可能です。PHP用のライブラリもあります。 Webhookでは特定のイベントが発生したタイミングでその情報をJSONデータとして設定したURLにポストします。 プラグインはほぼWebHookと同じ仕組みです。プラグインは標準で21個提供されています。 MAで何を解決したいのか？ スタンドアローンで運用するのではなく、既存のITインフラと接続し付加価値を生み出す仕組みが重要だと考えています。 APIを利用した例 SFA/CRMとの連携 Salesforce上の顧客データとMauticの連携 ChatOps 新しいコンタクトが追加されるとSlackにメッセージが来る CMS連携 既存のWebサイトとの連携。例えばDrupalで登録するとMAにもデータが登録される。 Mauticによって誰でもMAが実現できるようになりました。自社のサービス、プロダクトと接続できるのでビジネスチャンスが広がるでしょう。 Splunkでビジネスアナリティクス?世界的に有名なお客様の事例をご紹介します Splunk Service Japan Senior Partner Sales Engineer 小松原 貴司さま Splunkにはログ解析だけでなく、ビジネスを伸ばす仕組みがあります。マシンデータをすべての人にアクセス可能に、便利なものに、そして価値あるものにというのが我々のポリシーです。 今回はその例を紹介していきます。 REST APIでデータを登録します。スマホアプリのすべてのデータをSplunkに送信しています。例えばスマホの上下を判断してヒートしているかどうかを判断したり、Splunkにデータを登録します。それによって飲み物や食べ物の消費が変化します。負けているチーム側は美男美女の売り子を送り込みます。ゲームの状況によってコーラ、ビールなどを調整します。 駐車場のデータも統合されているので、席の近くの駐車場を案内する仕組みがあります。 アメリカのゲーム会社、Ubisoftのバックエンドで使われている事例です。ユーザのジャンプなど、ゲーム内の動作すべてビッグデータに入っています。現在、ゲームの世界は殆どAPIベースになっています。それらを測定し、サービス単位の処理速度も分かります。ABテストをゲームの中で行っているのも分かります。その反応もSplunkで取れます。その結果、課金やポイント取得などをリアルタイムに可視化できるます。 エラーも分かります。すべてを直すのではなく、良く発生しているものから対応するのが現在のやり方です。他にもAPIの負荷予測システムがあります。それを越えた値が出ると、アラートが出るようになっています。 懇親会&LT 発表後は懇親会とLTがありました。今回は3人の登壇者がありました（お一人は非公開）。 資料はこちら マーケティングとテクノロジーを組み合わせるとどんなことができるのか、注目の分野ではないでしょうか。懇親会でも大いに盛り上がっていました。

これから新機能をマイクロサービスとして作る場合、どういった用途であれば向いている言えるでしょうか。向き不向きを正しく把握できれば、開発しやすく、かつメンテナンスしやすいシステムが作れるはずです。 1アクセスが1秒以下 サーバレスアーキテクチャは長時間のアクセスが求められるような仕組みは不向きです。そのため、データベースもRDBMSよりNoSQLであったりKVSのものが向いていると言えます。一瞬のアクセスで結果を受け取って返す、といったものが向いています。 長時間の処理が必要なものは現状のサーバ環境を使った仕組みのが安心でしょう。 短いロジック 基本的にマイクロサービスでは1つのサービスが1つの処理を行います。そのため自然とコード量も短くなるでしょう。あまり長くなると処理時間もかかってしまいます。必要があれば複数のマイクロサービスを組み合わせることもできるでしょう。 APIが1URLに対して1リソースとして独立性、明確さをメリットとしているようにマイクロサービスも1つ1つのURLでできることを明確にすることで使いやすくなります。 大量のアクセスが発生する サーバで大量のアクセスをさばこうと思うと相当なリソースが必要ですが、サーバレスアーキテクチャの場合は気にすることはありません。大量のアクセスをまとめて処理できます。かつ、処理が終わったらサーバが存在していないのと同じで料金もかかりません。 ただし大量のアクセスによってバッグエンド側に影響を及ぼす可能性があります。サーバレスアーキテクチャが問題なかったとしても、従来のアーキテクチャ部分が残っていると、そこがボトルネックになるはずです。 リアルタイム性が求められない サーバレスアーキテクチャの欠点として、最初の処理に対してレスポンスが非常に悪いという問題があります。これはリクエストによって実行環境がデプロイされるためです。一度起動した後、アクセスがあればしばらく実行環境は残り続けるのでレスポンスは維持されます。 そのため、利用側としても即応性が求められるような場所には利用しない方が良いでしょう。もちろん常にアクセスが発生しているならばレスポンスが良いはずですが、それも100%とは言い切れません。 機能の独立性が維持される サーバレスアーキテクチャでは個々の機能単位でコードが独立しています。そのため、一部だけライブラリをバージョンアップしたりハードウェアリソースをアップグレードすることもできます。複雑性を増すのであまりお勧めしませんが、柔軟なシステム構成を実現できるでしょう。 開発陣が大きなチームになってきた時、システム全体を把握するのは大変ですがマイクロサービスであれば個々のシステムについて理解していけば良いというメリットがあります。 APIファースト マイクロサービスでは基本的にJSONやXMLを返却するものが多いようです。実際、APIをマイクロサービスで実現するのは相性が良いでしょう。マイクロサービス同士でメッセージを交換する際にもAPIが使われます。 逆にHTTPであったり、画像などを返すのであれば従来のアーキテクチャで十分と言えるでしょう。RESTful APIもリソース単位で独立しているように、サーバレスアーキテクチャでシステムを構築する際にはまずAPIを軸に考えていくのが良いでしょう。 マイクロサービスを突き詰めていくと何でもマイクロサービス化したくなります。しかし向き不向きがあり、向いていないものまで変えてしまうと却って変更やバージョン管理が煩雑になったりします。決して銀の弾丸ではありません。 特性を正しく判断してサービス開発に活かしてください。

サーバレスアーキテクチャの代表例として知られているAWS Lambda。今回はそんなLambdaがどんな目的で使われているか紹介します。 CI 継続的インテグレーションをLambdaで行う方法です。昔はCIサーバを用意するのが基本でしたが、開発用途のサーバを構築、メンテナンスするのは手間なのでLambdaで代用することで運用コストを減らせるようになります。 この時に使われるのがWebHookです。GitHubなどのリポジトリサービスはコードアップデート時のWebHook通知に対応していますので、その通知先をLambdaにすることでテストが自動的に行われるようになります。 テキスト処理 テキストの分かち書き処理であったり、大量のテキストを一気に処理する場合にLambdaが使われます。一定期間だけ大量の処理能力が必要な場合、クラウドサーバを立ち上げるのがこれまでのやり方でしたが、これでは料金が高くなってしまいます。 処理範囲が限定的な場合、Lambdaを使うことで料金を大幅に下げられるようになります。サーバを立ち上げる前に、これはLambdaでもできるのではないかという考えは今後大事かも知れません。 チャットボット 最近事例が多いのがチャットボットです。ロジックについてはあまり書かず、メッセージを受け取ったらAI系、テキスト処理系のAPIに送信します。そして、その結果をチャットとして返却します。仕組みは単純で、テキストメッセージ向きの仕組みと言えるでしょう。 ただしインタラクティブな対話を行おうと思うと多少面倒かも知れません。データの保存場所も残しておく必要があるでしょう。 問い合わせフォーム Webサイトによくあるお問い合わせフォームですが、Lambdaを使うことでサーバ側のロジックレスで構築できます。仕組みとしてはAmazon S3のJavaScript SDKによってお問い合わせ内容をAmazon S3上に保存します。そして、それをフックとしてLambdaを実行してメール送信します。 Lambdaの場合、単独での利用もさることながら、S3や○といった他のAWSのサービスと組み合わせて使えるのが魅力的ではないでしょうか。 APIサーバ Lambdaを使ったAPIサーバとしては、まずフロントにAPI Gatewayを使ってアクセスを一手に行います。そして、リクエスト内容に応じてLambdaを実行して結果を返却します。Lambdaを使うことで相当数のアクセスが来ても安心なアーキテクチャになります。API Gatewayによってアクセス数を制限することもできるでしょう。 APIサーバとしてのデータソースはデータベースを使うこともできますし、Amazon S3上に保存したCSVファイルを使うこともできます。後はファイルを差し替えるだけでAPIデータの更新も実現できます。 サーバレスアーキテクチャが最近の注目ワードですが、すべてのサーバ環境が置き換えられるものでは決してありません。向き不向きがあることを認識する必要があります。特性が分かれば、システムの一部はサーバレスアーキテクチャに、一部はこれまでのサーバを使うと言ったハイブリッドな構成が有効になるのが分かるはずです。

ここ1、2年くらいで注目が集まっているのがマイクロサービスと言われるシステムアーキテクチャです。今回はそんなマイクロサービスの特徴を紹介します。 小さくシステムを定義して組み合わせる マイクロサービスはその名の通り、小さな（マイクロ）サービスに特化したアーキテクチャです。例えば認証/ユーザ管理や決済など特定の機能に特化した部分を一まとめにして構築します。バックグラウンドのデータベースについては共通化されていたり、クラスタリングを組んで参照については個々のマイクロサービスでデータベースを持っている場合もあります。 マイクロサービス同士はAPIを通じて情報を交換します。マイクロサービスとAPIは密接な関係にあると言えます。 更新が容易になる マイクロサービス同士は独立しているのが重要です。各サービスを疎結合にすることでスコープを明確にしたり、メンテナンスが容易になります。一つの大きなシステム（モノリシック）の場合、一つの変更が無関係な処理に影響を及ぼすことも少なくありません。マイクロサービスではそうした心配がありません。 とは言え、多くの場合共通した処理が必要になることもあります。モデルなども使い回したいというニーズもあるでしょう。そうした時には安直に共有化するのではなく、サービスのスコープを見直す必要があるでしょう。 システム全体の把握が容易になる システムは構築時よりも更新時に問題が起こりやすいでしょう。複雑なシステムになるほど、一つの修正が影響を及ぼす範囲が広くなっていきます。テストでカバーすべきところですが、共通ライブラリの変更は怖くて手がつけられなくなります。その結果としてコードのコピー&ペーストが増えていきます。 マイクロサービスの場合、独立性が担保されていますので修正が容易になります。担当者の知識が全体に及んでいない場合でも、レスポンスが変わらない限りは安心して修正できます。 複雑度が増すことが多い シンプルなはずのマイクロサービスですが、多数のサービスが乱立することで複雑に絡み合ってしまうことがあります。システムの粒度をあまり細かくすると、一つの処理を行うために複数のサービスを組み合わせなければならなくなります。HTTPのAPIを採用している場合、トランザクションがネックになってきますので複数のサービスを呼び出すのは現実的ではありません。 また、サービスが別なサービスを呼び出すのも避けた方が良いでしょう。一つのサービスへの負荷が高まる可能性があり、結果としてボトルネックになってしまいます。クライアント側からのみ呼び出す方がシンプルさを保てるようになります。 実行速度の問題 複数のサービスを呼び出す仕組みにした場合にボトルネックになるのはネットワーク速度です。一部の処理においては並列化させることもできますが、ネットワークコネクションコストは積み重なると無視できなくなります。 一つの解決法としてプロキシサーバを立てる方法があります。プロキシサーバが複数の処理を一手に受け付け、各マイクロサービスで処理を実行して結果を再度束ねて返すようにします。これによってクライアントとプロキシサーバ間のネットワークコストが大幅に減らせるようになります。 移行が容易 レスポンスが保証されている状態であれば、バックエンドのプログラミング言語やデータベースが変わったとしても問題ありません。モノリシックな場合はプログラミング言語の移行やバージョンアップに対して臆病になりがちです。マイクロサービスの場合は、一部のシステムから順番に変更できるようになります。 ビッグバンアップデートにならない分、スムーズな移行が実現できるようになります。 RESTful APIが基本 マイクロサービスの通信にはAPIが欠かせません。その多くはRESTful APIとなっており、CRUD操作が容易にできるようになっています。認証についてはその部分だけがマイクロサービス化されており、OAuth2によって認証/権限管理されているのがデファクトになっています。 ただしマイクロサービスが増えると権限を付与する操作を何度も行うことになります。そうした問題を防ぐため、システムによっては一度の承認でマイクロサービス全体のシステムで使えるようにするケースもあります。 マイクロサービスが向いているのは継続的な更新が続けられているシステムになるでしょう。一度作って、その後は殆ど更新しないような業務システムなどはモノリシックな方が開発、メンテナンスしやすいでしょう。 そしてマイクロサービスの問題はスコープにあります。粒度があまり細かいとシステムの複雑度が増したり、コードの共有が増える傾向にあります。ユースケース単位で区切ったり、帳票やバッチ処理など相互に影響を与えない部分を切り出してマイクロサービスにするのが良いでしょう。

マイクロサービスとは マイクロサービスとは、単一のアプリケーションを小さなサービス群の組み合わせとして構築する手法です。それぞれのサービス同士は疎結合とし、RESTful APIなどで接続をおこないます。そのアーキテクチャを支えるため、各言語でマイクロサービスフレームワークが存在します。今回は、言語ごとに主なソフトウェアをピックアップして紹介します。 PHP Lumen LaravelがベースとなるPHPのマイクロフレームワークです。ベンチマークではPHP系マイクロフレームワークで最速としています。またLaravel開発者であれば、再学習することなく利用できるでしょう。フルスタックのLaravelにコードをコンバートすることも可能で、Laravel開発経験者なら選択技として大きなアドバンテージになるでしょう。 License: MIT license Lumen - PHP Micro-Framework By Laravel Slim Framework Slimは、シンプルで強力なWebアプリケーションやAPIをすぐに書けるPHPのマイクロフレームワークです。Webのマイクロフレームワークとして、HTTPのルーティングは当然ですが、PSR-7をサポートするのでHTTPメッセージを作成するのも容易でしょう。 License: MIT license Slim Framework Silex Symfonyをベースに開発され、SinatraにインスパイアされたPHP製のマイクロフレームワークです。 直感的で簡潔なAPI 拡張システムとしてPimple micro serviceを持っているため、拡張も容易 リクエストとレスポンスを抽象化するSymfonyのHttpKernelを使用しているのでテストが容易 といった特徴を持っています。 License: MIT license Silex - The PHP micro-framework based on the Symfony Components Python Flask FlaskはPython用のマイクロWeb開発フレームワークで、2010年頃から開発されています。その概念は「フレームワークの簡易性やフレームワークの小さいものというだけでなく、フレームワークで書かれた、複雑さとアプリケーションのサイズに制限をかけたもの」 としています。 License: three clause BSD License Welcome | Flask (A Python Microframework) Bottle Bottleは高速、シンプルかつ軽量なPythonのマイクロWebフレームワークです。単一のファイル・モジュールとして配布され、Python標準ライブラリ以外の依存関係がないとされています。 License: MIT License Bottle: Python Web Framework Pyramid Pyramidは「小さく、早く、堅実」を謳うPythonのマイクロサービスフレームワークです。インストールからスクリプトの起動まで、非常に簡単にセットアップ可能です。Python系はPythonコンソールからすぐに実行できるものが多いのが特徴です。すぐにサンプルスクリプトの確認も可能でしょう。 License: Repoze Public License The Pyramid Web Framework Java Lagom Lagomはスウェーデン語で「十分な」と言う意味です。開発者によると、マイクロサービスのマイクロを強調したくないとの理由から命名され、丁度良い適切なサイズのサービスを作成することを目的として開発されました。ドキュメントなどを確認すると、Javaというより、Scala色が強い感じです。現時点ではJava APIが用意されていますが、Scala APIも開発中のようです。 License: Apache2 License Lagom まとめ いかがでしょうか。全てを紹介できないほどで、マイクロサービスを謳ってるフレームワークが多くある状況です。他にもマイクロサービスを支える基盤となる、アーキテクチャフレームワークも存在します。ぜひ自分の好きな言語でマイクロサービスフレームワークがあるか調べてみてください。

9/27@サンフランシスコにて開催されたApigee主催の ADAPT or DIE の速報レポートその３です。 午後からのセッションをご紹介します。 その他のセッションはこちら * その1 * その2 会場はサンフランシスコ Market StにあるVillageです。 午後からも引き続き各種セッションがありますが、まずはAdapt or Die Movieのご披露。 ハリウッドさながらの演出はさすが。Apigeeスタッフも出演！ 20分ほどの上映のあとは、Innovation Showcaseです。 以下3社よりユースケースの紹介がありました。 Peter Miron - Software Architect—Advanced Technologies Group, Apcera Todd Thayer - Senior Director Software Developer Programs, Silver Spring Networks Alex McClure - Sr. Product Manager - Platform/API, Mindbody Silver Spring Networks IoT Platformを手がける企業で、Network Platform、Control Platform、Data Platformなどを提供しています。 APIも充実しており、 ここから Data Platform API Docsを確認できます。 デバイスやイベントのサーチAPIや、各種イベントを通知するWebhook API、その他ネットワーク系だとデバイスとん疎通確認ができるPING APIなんかもあります。 Mindbody APIによって様々な企業と提携して、Fitness Mobile Appsを作ってる話。 31万ユーザが関連している55,000のビジネスをカバーしているとの事。 米国の文化をうまくビジネスに仕立て上げた良モデル。 そして、いよいよラストのセッションが始まります。 「Closing Keynote」 Closing keynote with Apigee CTO, Anant Jhingran Open API Specification Throughout the API Lifecycle API Lifecycleを「Speed Matters」に例えます。 そして、Apigeeを使えばVery Goodな「Speed Matters」が完成するんです！ 以上、今年は1dayでの開催でしたが、とても内容の濃い充実した1日でした。 レポートでは書ききれませんでしたが、別のフロアではApigee PartnerによるRoundtablesも開催されており、こちらもまた盛り上がっておりました。 来年はもしかすると別のイベント名になっているかも？ですが（特に触れられてませんでしたが）、さらにパワーアップしたイベントになっていることを期待します。 ハッシュタグ[# DigitalKnowHow]