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年で進んだこととすれば，次の事柄がホットトピックと言えるでしょうか。

• OAuth 2.0がよりAPIとして標準化が進んだ
• OAuth 2.0を認証（AuthN）プロトコルとして安全に用いることができるOpenID Connectの普及と周辺仕様がだいぶ整備された
• OAuth 2.0/OpenID Connect 1.0で用いられているJSONのSigning/Encryption(JOSE)の周辺仕様が充実した

例えば，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年はまさに過渡期で，様々な会社が自らがフォーカスすべき開発対象に取捨選択を迫られる年になるのではないかと思っています。

当たるも八卦，当たらぬも八卦ということで。みなさまの一年が素晴らしいものになりますように。