みなさま、あけましておめでとうございます。zigorouです。昨年までソーシャルWebというキーワードでよういちろうさんが執筆されていた新春企画（昨年の記事）の後継として、APIに関する分野での技術動向やビジネス動向などを大胆に予想していくことになりました。今後おつきあいいただくかと思いますが、よろしくお願いいたします。
HTTP/1.1の再整備
2015年の一つの大きなニュースとしてはHTTP/1.1が再定義され、さらにHTTP/2が登場したことでしょう。これらの仕様群はHttpbis Status Pagesで一覧を見ることができます。
HTTP/2については後述することにしてまずはHTTP/1.1を考えてみると、HTTP/1.1の再整備によって、曖昧だった仕様の定義が厳密になり実装間での差分が小さくなっていくことが予想できます。
例えば、RFC7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentではREST APIという観点では大きな意味合いを持ちます。4. Request Methodsでは安全なメソッド（Safe Methods）やベキ等なメソッド（Idempotent Methods）だけでなく、キャッシュ可能なメソッド（Cacheable Methods）などを明確に定義し、その上で各メソッドがどのようなシチュエーションで用いられるのかが今までより正確に記述されています。さらにAPIの世界でも実は利用価値の高い5.3. Content Negotiationも再整備されました。多言語対応しなければならないリソースを持ったREST APIを提供する際に熟読すると良いでしょう。
さらにRFC7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requestsでは、条件付きリクエストについて詳細に定義されました。これまでREST APIで条件付きリクエストがサポートされることはそう多くなかったわけですが、HTTPの標準的な枠組みにおいてクライアントサイドのデータが最新かどうかを検証したり、安全にデータを更新したりといった枠組みが詳細に定義されています。こちらも今後のREST APIで積極的に採用していきたい枠組みだと思います。
RFCがきちんとそうしたことを言及することで、HTTP ServerやProxy Serverだけでなく、今後はAPIもきちんとHTTPの語彙に沿った実装によって、RESTの世界観が進化していくでしょう。
HTTP/2の登場
さて、2015年はHTTP/2がついにRFC7540 Hypertext Transfer Protocol Version 2 (HTTP/2)としてまとめられました。既に実装も多数登場しています。例えばサーバーで言えば、nghttp, jetty, h2o, nginx, apache2などが挙げられ、ブラウザ側の対応状況も進んできています。HTTP/2の技術的な特徴は既に様々な場所で語られていますが、以下が挙げられます。
- HTTP/1.1のセマンティクスを変えない
- より高速な通信（接続やフロー制御の効率化、バイナリプロトコル化など）
- サーバープッシュ
このプロトコルの実装者にとっては2.が最も重要だと思いますが、APIという観点では1.が担保されている点に加えて3.のサーバープッシュがWebのサーバーサイドアーキテクチャを大きく変えうるポテンシャルを秘めていると考えています。
サーバープッシュの応用例として2つ注目している枠組みを紹介します。
Cache aware Server Pushは、HTTP/2 serverの実装の一つであるh2oが提案している静的コンテンツのアセット（例えばCSSファイルやJSファイル群）配信にサーバープッシュを用いた際、いかに効率的に各ファイルのCacheがinvalidateしているかを検出するための仕組みです。私が下手に解説するよりもJxckさんのHTTP/2 PushをService Worker + Cache Aware Server Pushで効率化したい話のエントリを読んだほうが良いでしょう。このエントリでも言及されているように、ブラウザキャッシュのレイヤがFingerPrintの計算を行いCookieやCache-Fingerprintヘッダを送出するようにすれば良いのですが、過渡的な対応としてブラウザキャッシュではなくService WorkerのCache APIでキャッシュさせて、FingerPrintの計算をService Workerに行わせるというのがとても優れたアイデアだと思います。これらの仕組みがh2oのリードプログラマの奥一穂さんによってドラフトとしてまとめられています。
次にPush APIの話です。こちらはクライアントサイドの対応状況から見てみるとChromeとFirefoxのみが先行しています。身近な例で言えば、ChromeでFacebookを閲覧している方はお気づきかもしれませんが、FacebookがPush APIを利用した通知を行っています。ChromeのバックエンドはGCMですが、Firefoxのバックエンドは純粋なHTTPプロトコルで行われているようです。Push APIのバックエンドをWebベースにするための議論はWeb-Based Push Notificationsで議論されています。この議論の延長線上にもおそらくHTTP/2のサーバープッシュを利用していく話が出てくるのではないかと思います（実際かつてGeneric Event Delivery Using HTTP Push draft-thomson-webpush-http2-02のようなドラフトが出ていました）。
サーバープッシュはこれらの事例だけでなく他にも応用可能なテクノロジーになると考えられます。2016年も目が離せない技術だと思います。
JSONを取り巻く環境の変化
すっかりWeb APIのスタンダードフォーマットの地位を確立したと思われるJSONですが、その表現の自由度からまだまだ整備されなければならないことがたくさんあります。例えば次のような概念です。
- エラーレスポンスフォーマット
- Hypermediaフォーマット
- Schema
- RESTとのさらなる融合
エラーレスポンスフォーマットに関してはProblem Details for HTTP APIs draft-ietf-appsawg-http-problem-02がRFCになりそうな勢いです。これまで様々な独自フォーマットが跋扈していましたが、これにて一件落着となりそうです。
HypermediaフォーマットとしてはHAL, JSON-LD, Collection+JSONなど群雄割拠ですが、どれも一長一短ありそうで簡単にはこれだと決定するのは難しい情勢です。筆者の仕事でHALを適用しようと試みたことがありましたが、HALではないPure JSONフォーマットと著しく異なり、またHALで表現できることとJSON Schemaの相性が悪過ぎて結局止めてしまいました。
Schemaに関して言うと、JSON Schemaのdraft-04がもはやデファクトスタンダードです。実装状況を見るにかなりの整備が各言語でなされています。一方JSON Schemaの現状の枠組みではまだまだ手の届かないことが多数あり、それらはv5 Proposalsというページにまとめられています。中でもTemplate syntaxの拡張はURI Templateの制約によるリソース定義への悪影響から解放される一つの大きいな解決策になっていたりします。またこの中で使われているRelative JSON Pointers draft-luff-relative-json-pointer-00もアプリケーションへの応用が期待される素晴らしい仕組みだと思っています。
さて、最後にRESTとの融合について触れます。このジャンルで一番標準化が進んでいるのはJSON APIではないでしょうか。APIのフォーマットについて、JSONドキュメントの構造やデータ取得の際のリクエスト形式やデータ操作についてかなり事細かく書かれており、REST APIをJSONで提供する際に大変参考になるでしょう。特にBulk操作については筆者も他であまり見たことが無い新しい概念ではないかと思っています。
認証・認可のテクノロジーの今後
もうみなさんもご存知の通りWebにおける認可（AuthZ）プロトコルはOAuth 2.0がデファクトとなりました。2015年で進んだこととすれば、次の事柄がホットトピックと言えるでしょうか。
例えば、RFC7591 OAuth 2.0 Dynamic Client Registration ProtocolやRFC7592 OAuth 2.0 Dynamic Client Registration Management Protocolの整備は、事業をプラットフォーム化したい事業者と、プラットフォームの基盤技術を持つ開発会社にとって、プラットフォーム上のアプリケーション管理を円滑に行う枠組みを提供するものです。今後はこうした枠組みも利用しながらプラットフォームと連携するアプリケーション開発が進化していくと思われます。
RFC7662 OAuth 2.0 Token Introspectionは発行されたアクセストークンの状態を問い合わせることができる仕組みですが、認可サーバーとそこにぶら下がるMicroservicesを構築する上で一つのソリューションになり得るでしょう。MicroservicesとOAuth 2.0というジャンルではまだまだこれから発展していく技術領域だと考えられます。
また、Mobile ApplicationとOAuth 2.0も発展途上の仕組みですが、RFC7636 Proof Key for Code Exchange by OAuth Public Clientsによって懸案の一つであったCustom URIの乗っ取りに対する解決策が出てきました。今後Mobile Application領域への応用をより具体化するような動きが活発化されると予想されます。
終わりに
まだまだ語り尽くせない感はあるのですが、新春早々突っ込んだ話はここまでにして最後にこのような2015年の動きから予測できる2016年の発展がビジネスにどのように寄与していくかを考えてみましょう。
まず、HTTP/2やService Workerのくだりで指し示したようにリアルタイムWebが加速していくでしょう。
各事業者はウェブブラウザを用いたコンテンツに対して即時性のあるコンテンツの提供をしていくのが当たり前のようになっていくと思います。そうしたコンテンツを提供するためのアプリケーション開発やインフラストラクチャーの構築について真剣に見直し改善していくことが求められるのではないでしょうか。特にこのような技術革新はPCブラウザへの対応が最も安定しており、例えばゲーム開発であればクロスプラットフォームの一つとしてPCにも対応していくといった動きが大きくなってくると思います。
また、競合プラットフォームとの技術的優位性を持つために、APIを支えるテクノロジーもより重用視されていくでしょう。
Mobile ApplicationからPCブラウザまで広い意味での多様なインターネット端末がある中、例えばアカウントを中心にしたプラットフォームを提供して行く上で、認証・認可を始めとしてそれらをMicroservicesとして展開していく一連の流れはもはや止まりません。
AWSやGCPは、事業者が本質的に興味を持つべきはサービスを支えるビジネスロジックであるMicroservicesや、それを用いたフロントエンドに集中すべきで、それらを支える周辺技術をすべて一括りにインフラストラクチャーとして捉えているはずです。そのような前提に立つと2016年はまさに過渡期で、様々な会社が自らがフォーカスすべき開発対象に取捨選択を迫られる年になるのではないかと思っています。
当たるも八卦、当たらぬも八卦ということで。みなさまの一年が素晴らしいものになりますように。
