皆様、
JSONを巡る動き
RFC 8259の策定
まず直近の2017年12月に策定されたRFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Formatに触れない訳にはいかないでしょう。簡単に要点を列挙すると以下のようになります。
- このRFC 8259はECMA-404との統合がなされ、
今後これらの仕様が足並みを揃えて更新されるようになっていきます。 - 8.
1. Charactor Encoding に示されるとおり、原則JSON textはUTF-8でエンコードされないといけなくなりました。 - 8.
2. Unicode Charactors に示されるとおり、JSON textはUnicode文字列で構成されなければならなくなりました。
仕様が統合されて、
JSON Schema draft-07の発行
JSON SchemaはImplementationsを見てみると分かりますが、
なお、
- Core
- Validation
- Hyper Schema
CoreとValidationは同列に扱うことが多いため、
- CoreとValidation
- Hyper Schema
- 04から06への大きな変更点は、
Link Description Objectの取り回しです。オペレーション (HTTP Methodのこと) ごとに記述だったものが、 リソース単位で記述するような変更になっています。ある意味、 よりREST色が鮮明になりました。統一インターフェースで表現できる文脈においては、 より平易に記述できるになったと言えそうです。 - 06から07は一部のキーワードのリネームにとどまっています。
- 04から06への大きな変更点は、
既にTest Suiteにもdraft-07が追加されていることから、
ポストREST時代の到来?
RESTは長らくWeb APIの中心であり続けてきましたが、
- RESTの規約が曖昧かつ周知されておらず、
APIの利用者である開発者からみると結局ドキュメントを読んでみないと使い方が分からない。 - 必要な情報を都度取得する必要があり、
N+1クエリのような問題が多く発生するため、 モバイル時代のAPIとしての要請に応えきれていない。
そうした経緯からポストRESTを探る動きは数年前から進んできています。その代表格に挙げられるのがGraphQLとRPC
ここではGraphQLを取り上げてみます。
GraphQLはFacebookやGitHub、
- 余分なフィールドを取得しないようにできる
- 関連するオブジェクトを一回のクエリで取得できる
またクエリだけでなく型システムを持ち、
簡単な紹介ですが、
終わりに
今回も2017年に筆者が気になったテーマをいくつかピックアップして見ました。データフォーマットの主流がJSONである流れ自体はそう簡単に変わらないと思われますが、
パブリッククラウドの提供するサービスの進化も睨みつつ、