2018年のAPI動向

皆様、新年あけましておめでとうございます。今年も昨年の特集に引き続き、2018年のAPI動向を探っていきたいと思います。新年早々の記事なので当たるも八卦、当たらぬも八卦。気軽な気持ちで読んでみてください。

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を見てみると分かりますが、広く普及しているのはdraft-04になります。draft-05はdraft-04を整理しただけなので、draft-07へのマイグレーションという意味では事実上draft-04とdraft-06を確認すべきです。どのように進化しているかをdraft-04を起点に見ていきます。

なお、JSON Schemaは次の3つの仕様から成り立っています。

Core
Validation
Hyper Schema

CoreとValidationは同列に扱うことが多いため、CoreとValidation、Hyper Schemaの2つに分けて変遷を見ましょう。

CoreとValidation

04から06には非互換の変更が含まれます。
一方で06から07ではリリースノートの冒頭に記述されているとおり、完全に後方互換性が保たれています。
04から比較すると検証ルールの記述がより明確にできるようになったことと、$idの取り回しが大幅に変更になった点が大きいと思います。

Hyper Schema

04から06への大きな変更点は、Link Description Objectの取り回しです。オペレーション（HTTP Methodのこと）ごとに記述だったものが、リソース単位で記述するような変更になっています。ある意味、よりREST色が鮮明になりました。統一インターフェースで表現できる文脈においては、より平易に記述できるになったと言えそうです。
06から07は一部のキーワードのリネームにとどまっています。

既にTest Suiteにもdraft-07が追加されていることから、今後実装が増えてくることが予想されます。以前も紹介したOpen API Specificationとともに、JSONベースのAPI開発においてのツールチェインとしての中心になるでしょう。

ポストREST時代の到来？

RESTは長らくWeb APIの中心であり続けてきましたが、近年その融通の利かなさから敬遠する論調も多く見られるようになってきました。様々なポイントがありますが、主要な論点としては以下が挙げられるでしょう。

RESTの規約が曖昧かつ周知されておらず、APIの利用者である開発者からみると結局ドキュメントを読んでみないと使い方が分からない。
必要な情報を都度取得する必要があり、N+1クエリのような問題が多く発生するため、モバイル時代のAPIとしての要請に応えきれていない。

そうした経緯からポストRESTを探る動きは数年前から進んできています。その代表格に挙げられるのがGraphQLとRPC（例えばgRPC）ではないかと思います。

ここではGraphQLを取り上げてみます。

GraphQLはFacebookやGitHub、Pinterestなど主要なサービスが採用しているクエリ言語です。具体的にはデータの取得であるqueryか、データの更新であるmutationを用いて、特定のエンドポイントを介してデータにアクセスします。特にクエリにフォーカスして言えば、RESTよりGraphQLが優れた点として次の項目が挙げられます。

余分なフィールドを取得しないようにできる
関連するオブジェクトを一回のクエリで取得できる

またクエリだけでなく型システムを持ち、GraphQLサービスの型を独自のスキーマ言語で厳密に記述できます。型が厳密に定義できるため、クエリの検証が容易に可能な点も見過ごせません。

簡単な紹介ですが、GraphQLがRESTに取って代わり得るポテンシャルを秘めているのが理解できると思います。APIのサービスプロバイダがGraphQLサービスの実装についてより具体的に挑戦していくことで、多くのサービスがGraphQLをサポートしていけば、APIの利用者である開発者にも身近な存在となって普及が進んでいくのではないでしょうか。過渡期においては公開APIのクエリはGraphQLもサポートしつつ、バックエンドはRESTなどといった構成を取るサービスプロバイダなども出てくるかもしれません。いずれにせよ今後の動きが楽しみです。

終わりに

今回も2017年に筆者が気になったテーマをいくつかピックアップして見ました。データフォーマットの主流がJSONである流れ自体はそう簡単に変わらないと思われますが、RESTが今後も使われ続けるものかどうかは、サービスプロバイダと開発者それぞれの体験に対して、どれだけ優れたツールチェインが用意されていくかによってトレンドが大きく変わっていくのではないかと感じています。

パブリッククラウドの提供するサービスの進化も睨みつつ、2018年もまだまだスタンダードと言える環境が整わないのではないかと思っています。プログラマーの方はこれらの環境整備のために何かしら興味のある分野を見つけてコントリビュートするのも一興ではないでしょうか。