みなさま，あけましておめでとうございます。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の技術的な特徴は既に様々な場所で語られていますが，以下が挙げられます。

1. HTTP/1.1のセマンティクスを変えない
2. より高速な通信（接続やフロー制御の効率化，バイナリプロトコル化など）
3. サーバープッシュ

このプロトコルの実装者にとっては2.が最も重要だと思いますが，APIという観点では1.が担保されている点に加えて3.のサーバープッシュがWebのサーバーサイドアーキテクチャを大きく変えうるポテンシャルを秘めていると考えています。

サーバープッシュの応用例として2つ注目している枠組みを紹介します。

• Cache-aware Server Push
• Push API

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年も目が離せない技術だと思います。