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]

9月27日、サンフランシスコにてAdapt or Dieが開催されました。昨年は、I Love APIで3日コースでしたが、今年は1日に圧縮で、5都市で実施とのこと。先日、Googleが買収を発表したApigee主催のイベントでいろいろ興味深いところです。こちらはそのレポートになります。その1に続いて、クラウドとマイクロサービスセッションをレポート。 Adapt or Die Microservices with Node.js and Docker： 登壇者：Tony Pujals - Director of Cloud Engineering, Appcelerator Microservices and Docker 昨年のイベントでも公演されてました。たしか、node.js系だったかと。今年は、Dockerキャプテンとして。 基本はDocker紹介なんで、Docker1.1.2リリース概要。リリース概要みたら、1.1.3がでてました!! Docker Release Notes Docker Swarmのトポロジー説明。この辺りになってくると、K8との違いを質問する人もおりました。どちらにしろ、この世界は立ち上がり中なので、実際に利用してみるのがオススメです。 Plan for Swarn in Production Serverless Microservices 登壇者：Alan Williams - Enterprise Architect, Autodesk こちらは、Apigeeユーザ企業のAutodeskの人が発表です。Apigee + AWS Lambdaという感じです。 Serverlessのattribute。VMでもコンテナでもなく、コードがイベント要求で処理。 AutodeskのServerlessのバックエンドでAPI提供の事例。こういうのが今後たくさん出てくると思われます。 AWS Lambdaをサポートする、serverless.com あとで、利用してみます。 Serverless.com

9月27日、サンフランシスコにてAdapt or Dieが開催されました。昨年は、I Love APIで3日コースでしたが、今年は1日に圧縮で、5都市で実施とのこと。先日、Googleが買収を発表したApigee主催のイベントでいろいろ興味深いところです。こちらはそのレポートになります。 Adapt or Die Opening Keynote： 登壇者：Chet Kapoor - Apigee CEOなど 開始前の状況。こじんまりとしてますが、良い感じのイベント会場です。 Apigeeパートナー。プロダクトを核にした、エコシステムという感じでしょうか。 Apigeeプロダクトの近々および予定の列挙。 Proxy Chaining Kubernetes Integration Multi Cloud Integration Blockchain Shared flows/flowhooks New Developer Portal Sense Algorithms Federated Gateway GoogleがApigee買収したことにより、Kubernetes 統合が予定されてるようです。オープンソース化されると面白いですね。 Kubernetes Kubernetes: A Microservices Story at Google 登壇者： Allan Naim - Product Manager, Google Cloud Platform GoogleスタイルのCloudコンピューティング。 得られた知見として、オペレーションの切り離し。DevOpsが進むと、NoOps で、Googleで運用したきたコンテナ管理ノウハウを、Kubernetesに展開。これは普通の話。 Kubernetesに統合されるだろう、Apigee EdgeのコンテナクラスタAPIマネジメント構想。コンテナスケジュール管理と配置ディスパッチ、APIリソースパス単位で、必要なコンテナリソースへのアクセスをマネジメントするような構想でしょうか。

RESTfulなAPIを作ろうと思った時の参考になるのが RESTful成熟度の3レベルモデル です。自分たちのAPIがどの立ち位置にあるのかが分かれば、どう改善することでよりRESTfulとして成熟するかが分かるようになるでしょう。 レベル0 まず最初の状態ですが、これは XML-PRC や SOAP が該当するそうです。すなわち、一つのURLと一つのHTTPメソッドで後は送信されるデータで処理内容や処理対象が分かるという方法です。 レベル1 レベル1になると、まずURLが分かれます。しかしHTTPメソッドは変わらず一つです。例えばURLは行う処理によって分かれるものの、HTTPメソッドはすべてPOSTにするといった具合です。PUTやDELETEといったHTTPメソッドが活用されていない状態とも言えます。 レベル2 レベル2になるとURLが分かれているのはもちろん、メソッドも分かれます。CRUD（GET/POST/PUT(PATCH)/DELETE）に分割され、いわゆるRESTfulな状態になります。理想的なAPIとしてAmazon S3を挙げています。 レベル3 ではレベル3とは何でしょうか。それはAPIのレスポンスにハイパーリンク情報を持つことだと言います。例えばAmazon S3のレスポンスにはキー情報は含まれていますが、そのファイルをどういうURLで取得できるのかと言った情報は含まれません。開発者はドキュメントを読み、一定のルールに従ってURLを生成する必要があります。著者であるMartin Fowler氏によれば、Amazon S3はAPIとしては良くできているが、HTMLから学んでいないとのことです。 対してNetflixのAPIレスポンスではリンク情報が含まれており、APIがハイパーメディアとして動作します。これはHATEOASやHALに則った仕組みになります。そうすることで、開発者はどういったURLにアクセスすべきかというロジックを知らなくともAPIを利用できるようになります。 現在、殆どのAPIはレベル2になるでしょう。より利用を広めたり、使いやすいAPIを目指すのであればレベル3を目指すべきです。つまりハイパーメディアの考えを取り入れ、リソースを利用する際に開発者の負担を減らし、より柔軟な連携を実現しましょう。 JWTUMOIM: Act 3

JSONがAPIの基本フォーマットとも呼べる存在になって久しいですが、それによって逆にJSONが持つ緩さが問題になるケースがあるようです。そのため、多くの拡張フォーマットが作られています。 今回はその一つ、JSendを紹介します。JSONフォーマットに一定のルールをつけるだけでぐっと使いやすさが増すことでしょう。 JSendの基本フォーマット JSendのごく基本的なフォーマットは次のようになります。 { status : "success", data : { "post" : { "id" : 1, "title" : "ブログのタイトル", "body" : "ブログのコンテンツ" } } } 明確なルールは2つです。 1. statusを持つ APIのレスポンスを判断するためにstatusというフィールドを必ずつけます。これは3つの値を取ります。 値 説明 必須のキー オプションキー success 処理が成功 status,data fail 処理が失敗 status,data error システムエラー status, message code,data statusは必ずありますので、それを見れば処理が成功したのか失敗したのかがすぐに分かる訳です。 2. dataを持つ success/failの場合はdataフィールドを持ちます。処理が成功した場合には、ここにデータが入ってきますが、直接構造が入るのではなくpostのようなモデル名が入ります。もしこれが一覧の場合は次のようになります。 { status : "success", data : { "posts" : [ { "id" : 1, "title" : "ブログの件名", "body" : "ブログのコンテンツ" }, { "id" : 2, "title" : "別なブログの件名", "body" : "別なブログのコンテンツ" }, ] } } data以下のモデル名があることによって、複数のモデルを一回で返すといった仕様変更があってもすぐに対応できるようになるでしょう。 削除処理のように返すdataがない場合はnullを返します。 { status : "success", data : null } dataフィールドは必ず用意するのが原則です。 エラーの場合 入力エラーなど、アプリケーション側で発生させるエラーの場合は次のようになります。こちらはdata以下に入ります。入力エラーの場合にはエラー箇所が分かるようになっていると便利でしょう。 { "status" : "fail", "data" : { "title" : "タイトルは必須です" } } 対してシステムエラーが起きた場合は次のようになります。 { "status" : "error", "message" : "データベースに接続できません" } もちろん、JSONは返しますがHTTPステータスコードと組み合わせてエラーを作るべきでしょう。 JSendは制約が強くない分、導入しやすいかと思います。一定のルールに沿って提供されることで開発者にとって使いやすいAPIが提供できるでしょう。特に処理の成功、失敗、エラーが明確に分かるのは良さそうです。 JSend

xTech is the keyword for which we at the API team advocate. Now, we would like to present an overview of the concept. What is xTech? As of late, the buzzword "FinTech" has been making the rounds. This term was coined by combining the terms "finance" and "technology." Other well-known examples of the same type of term include AgriTech (agriculture + technology), EdTech (education + technology), and AdTech (advertising + technology). xTech is a general term for these portmanteaus of "________" + "Technology." What is the connection between xTech and APIs? So, how are APIs used with respect to xTech? APIs can be said to be the technological basis for almost every measure. APIs are used not only for inter-enterprise collaboration, but also for cases such as when multiple enterprises need to combine data, and when one company is adding content to its own services. If tasks such as these are not automated, the costs can increase, to the point that it defeats the purpose of adding value. This is not about bringing up the term "API" for just any old reason; APIs exist as an essential aspect of xTech. Why xTech now? FinTech, AgriTech, EdTech, and so on; what might be behind the appearance of so many xTech keywords? The normalization of a lifestyle in which, due to technological development and the popularization of smartphones, the internet has taken on a central role is thought to be one factor. Also, along with smartphones, sensor devices that interface with the "Internet of Things" exist in great numbers. It is said that in the course of our daily lives, data is generated moment by moment from our use of smartphones and web browsers, as well as from sensor devices. As the data collected in this way interacts with the conventional market, new forms of added value are coming into existence. Devices and sensors are appearing that can be put to use not only in fields such as AdTech that had been centered around technology all along, but also in domains such as education and medicine that had been largely unconnected to Internet technology. What We Need To Do? Those people whose work is connected to xTech can be divided into two main categories. The first group is comprised of people in the field of technology. By exerting influence on other markets, people working in technology have the chance to seize great opportunities such as API development, and collaboration with other enterprises. That being said, in some other markets, the investments being made in technology are not great, and there is a need to see examples of API management services being used for more agile implementation compared to developing from scratch, as well as successful demonstrations of starting small. There is also a major shortage of knowledge of other markets within the technology field, and as such, there is a need to study and understand them. The other group is comprised of those enterprises involved in fields such as agriculture, education, and medicine. For many of these enterprises, it is common for business to go well enough with traditional workflows, and there has to be a strong desire to further improve, expand, and develop new revenue streams. However, as knowledge of technology in these fields is insufficient, it may be good to start by consulting with a local system integrator or other expert. In this regard, what likely matters is not whether the enterprise is big or small, but whether it proactively undertakes efforts to move forward, and whether it has knowledge of xTech. xTech is a movement that began from last year. As it is only in its early stages, the next couple of years will likely see the arrival of new services and precedents. By all means, please join us in striving to take part in this movement.

In the last article, we discussed a summary of xTech. In this time, we write about what different fields there are. Use this list to check if there is a market developing around your field. Note that these names are not definite and may vary at times. FinTech This one needs no introduction: financial services mixed with technology. This field has shown major growth over the last few years, centered around banks. In many cases, individual contracts are required for API disclosure. A new economy is being built by FinTech firms. RetailTech The domain of logistics and inventory/warehousing. The field of logistics uses systems for efficient shipment, redelivery requests, etc. Advanced levels of technology were already in place in this area. In addition, use of big data accumulated in this area may allow for the creation of new services. MarTech Marketing paired with technology. Salesforce is a strong player in this area, with unique API economies and partnerships being built around CRM. Other uses of technology include e-mail marketing, marketing automation, performance measurement, etc. EdTech The education sector -- this field was very far behind in terms of use of the Internet, but tablet-based textbooks are slowly making inroads. MedTech The medical field has strong legal controls in place, but it has been revamping itself over the last few years. This includes remote medicine, simple diagnostics through AI, and the provision of medical care to areas lacking robust services. HRTech Human resources paired with technology. As with education and medicine, fields hinging on human interaction still tend to take an analog route. We are seeing changes in the way hiring is performed, with the use of data to visualize various metrics. LegalTech As the name suggests, this is the legal field. With global businesses on the rise, there is an increased need for responding rapidly to change while observing the laws of each country. Attention is also being paid to putting traditional business processes on the cloud. HealthTech The field of health is constantly drawing attention for technological innovations. Sensors can be used to monitor individual vital signs, with advice being given based on changes. AgriTech Agriculture had been behind in terms of penetration of IT technology, but the use of IoT sensors is visualizing data that had otherwise only been understood intuitively. Other efforts include reduced power consumption refinements. FoodTech Food, clothing, and house -- food is one spoke in this trio, and technological innovation is being explored here. Efforts are wide-ranging, taking take the form of things like home food deliveries and the development of fully-nutritive foods. SportTech Recent developments include wearing data-tracking bands while performing sports and sharing individual performance. Professional athletes are also using technology to visualize performance. FashTech The fashion industry is seeing changes involving the development of new materials and clothing with embedded sensors. Other experiments include futuristic fabrics with colors that change by mood. GovTech Technology in a government context. This largely involves the use of open data. Other activities include improving on and evangelizing about software produced by the government. AdTech Another one that needs no introduction is advertising technology. Since the introduction of search keywords, the advertising industry has been dominated by technology. RETech Real estate paired with technology. This field aims to automate residential loans, sale of used properties, rentals, et cetera. Many services are closely tied to finance. Other tech combinations are likely to grow in the future. It will be interesting to see how xTech ushers in changes to traditional analog markets.

RESTful APIはモデルごとにパスを作成し、IDをつけてCRUDなデータの操作を行えるようにしています。これはとても分かりやすい反面、クライアント側ではレスポンス形式を指定できないという欠点があります。 場合によって欲しいデータが異なる際には ?include=friends のようなパラメータをつけたり、別なAPIを追加したりして対応します。こうした拡張はRESTful APIに比べると打算的で、あまり良い設計になっていないことが殆どです。 そうした問題を解決できるかも知れないのがFacebookの開発している GraphQL というクエリ言語です。RESTful APIではありませんが、こうしたインタフェースを用意しておくのも使い勝手が良さそうです。 GraphQLとは GraphQLはHTTPを使ったクエリ言語と言えます。例えばユーザIDが1の名前を取得する場合は次のようにクエリを投げます。 { user(id: "1") { name } } そうすると結果が次のように返ってきます。 { "data": { "user": { "name": "Dan" } } } GraphQLを受け付けるエンドポイントは /graphql のように一つになっているのが望ましいようです。JSONでクエリを投げて、JSONで結果を返すようになっています。 バックエンドについて バックエンドのデータベースは任意のものが選択できます。MySQL/PostgreSQL/SQLiteなどが選択できます。実装はNode.jsで行われているものが多いようです。 データの更新について GraphQLはデータのクエリだけでなく、データの更新や削除にも対応しています。その際にはMutationという定義を使います。 mutation { addComment( postId: 42, authorEmail: "mark@fb.com", markdown: "GraphQL is clearly a **game changer***" ) { id, formattedBody, timestamp } } データ型を定義する GraphQLではクエリを実行した際にあらかじめ定義したデータ型に当てはめることができます。 type Droid : Character { id: String! name: String friends: [Character] appearsIn: [Episode] secretBackstory: String primaryFunction: String } このようなJSON風の言語を使って定義することで入力値の検証を行ったり、データにメソッドを追加したりすることができます。 GraphQLはクライアント側から欲しいデータを指定したり、データの更新を指示します。サーバ側の実装が減る一方で、クライアント側でロジックを実装する必要があるかも知れません。バランスを考える必要があるでしょう。 RESTfulではできなかった、より細かくデータを指定して取得するということがGraphQLを使うことで実現します。セキュリティ要件などは個別に実装していくことになりますが、技術的に面白いアプローチではないでしょうか。 GraphQL | A data query language and runtime

Swagger定義の管理場所について、 コード上に定義する方法 定義ファイルを直接管理する方法 API管理サービスを利用する方法 と、それぞれまとめました。 1. コード上にコメントとして記述する JavaDocのように、コード上のコメントとしてannotationで記述していく方法です。Swaggerを利用するにあたり、真っ先に思い浮かべるお馴染みの記述方法ではありますが、やはり一長一短があります。 長所 コード自体がリポジトリ管理されることで、APIの記述を別に管理する必要が無い。 *開発時にAPIのドキュメントの整合性が保たれやすい 短所 運用時においてはメンテナンスが行いにくい。 新規開発時なら導入はスムーズだが、すでに外部記述となっていた場合には相応のコストが掛かる。 annotationのコード補完が、エディタに備わっていない。 コード自体が長くなり、見通しの面ではデメリットになる。 メリットは傍受し、デメリットは工夫してカバーしていきましょう。 2. 定義ファイルとして記述する Swaggerの定義ファイルそのままを、ファイルで管理する方法です。一見、JSONをそのまま扱うので、デメリットしかないように感じますが、定義ファイルを分割することで、冗長的な記述を抑えるメリットがあります。 もちろん、定義ファイルを一意性を考えずにそのまま記述してしまうと、同じデメリットが発生します。これは、小規模のAPIであれば、問題は有りませんが、大規模APIとなると修正コストが問題になるでしょう。 分割したSwagger定義ファイルが増えると見通しの面では不利になりますが、メンテナンス面では改修を行うに当たって精神的にも楽になるでしょう。 実際にSwagger定義ファイルを分割して管理するツールは、執筆の現時点（2016-08-31）で存在していないと思いますが、いわゆるJSON定義を分割する方法ですので、以下のようなツールを利用してJSONを置き換える事が可能です。 whitlockjc/json-refs Swagger定義ファイルの分割については、また別の機会に紹介したいと思います。 3. APIサービスを使って記述する 各API管理サービスについても、Swagger記法が主流となりつつあります。既にAPIの管理サービスを選択するにあたり、Swagger記法があるかないかが導入の判断に関わることもあるでしょう。ここでは、Swagger定義ファイルがインポート＆エクスポートできるツールを紹介します。 Swagger Editor Swagger定義を管理できる、WEBサービスです。 Swagger Editor ツール自体は公開されています。プロジェクトで運用するのも選択の一つです。 licenseは、『Apache License, Version 2.0』となっています。 swagger-api/swagger-editor: Swagger Editor AWSの『API Gateway』 AWSの API Gatewayを利用しているのであれば、Swaggerのドキュメントを出力できます。 また、API GatewayにはImport機能も備わっており、 どちらもASW用に拡張機能の記述もできるようなので、AWSだけで記述を完結するようにした方が良さそうです。 今後のSwagger定義ファイルの管理 別の記述方法としてAPIBlueprintがあります。記述はAPIBlueprintで出力はSwaggerのJSONファイルで対応するという選択肢も出てくるかも知れません。 Swagger APIによる記述においては、様々な場所で開発できるのも強みであったりしますが、「開発とAPI定義がもっと便利にシームレスにできないか？」と思うところがあります。Swaggerの定義ファイルを管理するのは、API開発において避けては通れなくなってきています。今後もSwagger管理についてはウォッチしていく必要がありそうです。

8月25日、TAM CoworkingにてEnterprise APIs Hack-Night #6が開催されました。今回のテーマはEdTech×APIで、教育分野にフォーカスして3人の方に登壇いただきました。こちらはそのレポートになります。 講演1：プログラミング教育による破壊的イノベーション 登壇者：小金井市立前原小学校 校長 松田 孝様 一言に教育といっても色々と概念があります。学校教育に注目が集まりますが、家庭教育、生涯教育、社会教育などあります。学校教育は一部に過ぎません。さらに学校教育の中でも義務教育は一部で、私学では様々な試みが行われています。だからこそ、逆に公立は手つかずのブルーオーシャンと言えるかも知れません。 幸い私が校長を務める小金井市立前原小学校では私が率先していることもあり、多くのチャレンジが行われています。今回はそんな現場の生々しいとも言える現状について紹介したいと思います。そういった内情を知らずに「イイモノ」を作っても使ってもらえませんので注意してください。 まず公立学校の現状です。教室を見ても分かる通り、そこにはICT、IoT、プログラミングなんて言葉は全く感じられません。かろうじて液晶テレビとエアコンがあるくらいです。昔と何も変わっておらず、「子供たちはランドセルを背負って過去にタイムスリップしている」なんて言われたりします。 そんな時代との乖離を教えてくれたのはタブレットです。私がいた愛和小学校の時、一人一台のタブレットを導入しました。現在、タブレットを入れているのは大阪などの方が多いが、学力調査は東北地方のが高いです。残念ながらタブレットの利用が教育水準を引き上げているという訳ではありません。 学校とは本来、最先端の技術を学ぶ場であったと考えています。今から20年後、2036年の教育現場を思い浮かべてもロボットが所狭しと動いている姿は全く思い浮かびません。学校の中と外では40年のギャップが存在するとまで言われています。それはなぜかというと、保護者の評価基準は自分たちが受けてきた教育にあるのです。「懐かしい」と言って喜ぶ姿がまさにそうです。これでは進化がないのも納得してもらえるでしょう。 ではどうしたら良いでしょうか。そのためにはまず学校と政府、自治体などの関係から見ていきたいと思います。 まず学校の設置者は誰かということです。これは3つあります。 - 国 - 地方公共団体 - 学校法人 公立学校教員を採用するのは誰でしょうか。これは都道府県です。ただし政令指定都市は別です。 次に都の教育委員会と地方の教育委員会、偉いのはどっちだと思いますか。採用、つまり人事権は都の教育委員会にあります。しかし実際の教育は地方の教育委員会が決めています。 さらに教育課程は誰が決められるか。年間の授業日数はあらかじめ決まっていますが、その内容である教育課程の編成権は学校長にあります。学校長はそういった権限を持っており、実は職員会議のようなものは開かなくても良くなっています。 他にも学校を取り巻くステークホルダーはたくさんいます。 - 教職員 - 教育委員会 - 保護者 - 子供 - 同窓会 - 地域 - 議会 これらのステークホルダーの関心事はばらばらです。校長先生が変わったことをはじめると、一定数の保護者はそれに反発するでしょう。それは議会に届きます。彼らは票が欲しいので、保護者の言うことを聞きます。そして議会は教育委員会に通達し、さらに人事権を持った議会によって校長は行動を制限されると言った具合です。そうした様々なステークホルダーによって外からの刺激が届かなくなっているのが現状でしょう。 過去において電子黒板のようなICTが導入検討された時期がありました。しかし全く使われていません。これは幾つかの理由があります。まず先生はとても忙しく、変化を好みません。また、既存教科の完結性や完成度がとても高いため、隙がありません。その結果、必要性や現状との親和性が低いために導入が進まないのが実情です。 そんな中、プログラミング教育は現状の問題を打破する最高の武器と考えています。プログラミングは子供たちにとってゲームのようなもので、楽しんで行っています。そしてプログラミング教育を通じて既存教育の問題を知っていくのが良いと考えています。 学校は勉強する場ではなく、自分で学び、仲間と学び会う場です。それがプログラミングによって実現しています。ロボットを使ったプログラミング教育によって、プログラミングが自分たちの世界を便利にしていくと言うことを実感できています。 最近、プログラミング必修化を巡る動きが幾つも行われています。有識者会議もあります。ただし時間数は各学校で決定となっており、ちょっとやって終わりと言った学校もあります。また、最近の会議では英語教育がメインになっており危惧しています。 今後、教師は単なるティーチャーからファシリテーターへと変わっていくべきだと考えています。 官民連携による「教育×クラウド」 登壇者：NTTコミュニケーションズ株式会社 第三営業本部 稲田 友様 世界のEdTechはどんどん進んでいます。数億円の資金調達であったり、買収も多数行われています。 そんな中、日本の現状はどうなっているのか紹介します。 現在、オンライン教育のプラットフォームを開発しています。その位置づけは「世界に先駆けて社会課題を解決するビジネスを生み出す。バーチャルデータのプラットフォームでは出遅れた。第二のリアルデータでプラットフォームを確立する」とされています。政府も危機感を持ち始めています。世界最先端IT国家創造宣言を出し、家庭と学校がシームレスにつながる教育環境を作ろうとしています。 ではそんな中、実際の教育現場ではどうでしょうか。まず大きな試みとしてプログラミング教育があります。一人一台の環境整備が進められています。例えば柏市で29年度からプログラミング教育を行われます。 国が行っているのが先導的教育システム実証事業です。教育クラウドプラットフォームはクラウドベースで、一人一台のタブレットを導入しています。総務省と文部科学省が連携し、APIを使ったアプリ連携なども行われています。 教育クラウドプラットフォームはいつでもどこでも学べる環境、さらにマルチOSやブラウザ、200以上のコンテンツにシングルサインオンできるシステムです。日本国内だけでなく、海外の日本人学校にも提供しています。教材はHTML5で作られています。自宅に帰ってからの学習も補助でき、動画を見た上で問題を解くといったこともできます。 今の計画ではオープンアーキテクチャでモジュール化していこうとしています。そんな中ではコンテンツとユーザが肝です。つまり開発者の皆さんが頼りです。コンテンツを充実させていき、学びが続いていく環境を作っていこうと考えています。 アナログからデジタルを見直す事例があれば教えてください 最終的にユーザが自分でデジタルがいいか、アナログが良いかを選択しています。それぞれが自分にとって一番良い残し方を選んでいます。実物があるという感覚が大事という人も多いです。 各学校で提供しているコンテンツは一緒ですか？ コンテンツは学校ごとに自分たちで選択して決めています。 オープンアーキテクチャは一般デベロッパーが参加できますか？ すでに公開されています。認証情報を含めて公開されています。 このプラットフォーマーは誰ですか？ 国のスタンスは民の中で広めていって欲しいという考えです。我々、NTTコミュニケーションズでも提供していこうとしています。仕様を考えるのは今は国と我々ですが、最終的には団体を作る予定です。 講演3：制作現場からみた「EdTech業界」 登壇者：株式会社エレファンキューブ代表取締役　支倉 常明様 学校だけではない教育現場を紹介します。これまでの経験で、3つのEdTech業界があります。 - 企業研修 - 子供向け - 個人の学び まず企業研修です。eラーニングは2000年代初頭にはじまりました。2005年には下火になり、2008年にはリーマンショックで一気に教育予算が減りました。その後ですが、市場は落ち着きつつあります。特に市場規模が縮小した訳ではありません。また、動画の活用が非常に増えています。従来は教材をインタラクティブに作っていたのですが、動画によって制作コストは小さくなっています。一言で言えばつまらなくなっていると言えます。 企業研修のこれからについてですが、革命的なものはなさそうです。このまま定着していくのではないでしょうか。そんな中、個人が持っているスマートフォンを利用した学習が加速していくでしょう。 次に子供向けです。これまでの流れとしては2005年に初のデジタル教科書が登場しました。そしてCoNETSが立ち上がり標準化が進められています。それまでは各社が独自に工夫をこらしてきたので、なぜ標準化しなければならないのかと不満の声もありました。 さらに元々は指導者用が多かったのですが、学習者用へと変わってきています。最近では通信教育各社から続々とデジタル版がはじまっています。また、ロボットプログラミング教材が多数出てきました。 今後についてですが、2020年にデジタル教科書が開始します。とは言え、まだまだ黎明期で何が効果があるかないのか、デメリットは何か分からないのが実情です。分からないから面白いとも言えます。変化のなかった教育現場がダイナミックに変化しています。今後、想像もできない教材や活用例が出てくるのではないでしょうか。 子供向けは企業研修と違って、各関係者の気合いが違います。 最後に個人の学びです。まずスマートフォンが普及し、ネットワークインフラが整ったことで、時間や場所の制約がなくなっています。MOOCsなど、高品質な教育コンテンツにアクセスできる機会が圧倒的に増えました。さらに有象無象の教育アプリがあります。半分以上はダメなものばかりですが、面白いものもあります。 代表的なものとしてはフィリピンの英会話があります。これもネットワークインフラの整備が進んだ結果と言えます。さらに英語さえできれば多くのコンテンツにアクセスできるようになっています。 現状は正直よく分かりません。しかし、これまでの格差（学びたくても学べなかったなど。地域やお金の制約）が是正されてきています。 今後はどれだけ「自ら学ぼう」という意識が熟成されるのか、ロボットやドローン、ウェアラブル端末、機械学習とか新しい技術が学びとどうつながるかが鍵ではないでしょうか。その中で思いもよらぬ革命がおきるのではないでしょうか。Pokemon Goなども技術的には昔からあっても使われ方によって革新的です。 EdTechはまだまだ面白くなると考えていますが、地味な市場でもあります。ダイナミックなレスポンスがなく、すぐには儲からないと言えます。アメリカのように何億ドル調達みたいな話にはなりづらいです。私の周囲でも教育は儲からないという話が多いです。 しかし将来につながる意義は大きいと考えています。個人が自ら学ぶ社会、日本だけでなく途上国への教育機会の提供などが魅力です。世界には話し合いなどせず、いきなり殴り合いをしたり、騙し合いが当たり前と言った社会がまだまだ存在します。そういったところにも教育機会が提供できるのがEdTechなのではないでしょうか。 「そんな方法が！」といわれるような、全く新しい学びの体験を作りたいと考えています。 企業研修で個人のスマートフォン利用が進んでいるとのことですが、会社はそれを望んでいるのでしょうか？ 今まで教育したくてもできなかったところにコンテンツが届けられるようになるんじゃないかと思います。従業員の人たちにマニュアルを読め、というのは難しいです。チェーン店などであれば入社前に動画を見て個々人で学んでもらうこともできるでしょう。通勤時間中に勉強できるのはメリットだと思います。 紙と比べて学習効果はどうでしょう？ まだ結論は出ていないのが実情です。ただデジタル、アナログはあまり関係ないと思います。デジタルのメリットとして過去問のようなものは、すぐに結果が返ってくるメリットがあると思います。 企業研修のモチベーションをどう維持すべきでしょう？ 途中で止めて確認問題を挟むという方法があります。動画を見ず、寝ているだけというを防ぐためです。聞くだけではつまらないので、考えさせてから聞かせたり、危機感を覚えさせてから学習させるのが効果的です。 この後、懇親会が開催されました。その途中、LTがあり私がデジタル教科書の中でも使われているAR技術を紹介しました。ゲームで注目されているARですが、実物の教科書に掲げることでスカイツリーを輪切りにして閲覧できる「動く教科書」であったり、旭山動物園のARReaderなどの事例があります。 ARを簡単に実現できる技術&サービスとしてWikitudeがあり、マルチプラットフォームに対応したARアプリが開発できます。 懇親会では皆さんが教育に関してディスカッションを重ねていました。 EdTechは次のFinTechという記事 もあり、非常に注目度の高い分野であると言えそうです。