新年明けましておめでとうございます。zigorouです。 今回も昨年の特集に引き続き、2016年を振り返りながら2017年のAPIに関わる技術動向などを予想していきます。
サーバーレスとフルマネージドサービスの台頭
これまではオンプレミスの環境やAmazon Elastic Compute Cloud（EC2）を代表とする仮想サーバーやECS（EC2 Container Service）など、サービスの実行環境は少なからずインフラによる運用を意識した構成にすることがほとんどでした。しかし、AWS API Gateway＋AWS Lambdaの組み合わせによるFunctions as a Service（FaaS）や、Google App EngineによるPlatform as a Service（PaaS）のようなフルマネージドサービスを使ったサーバーレスアーキテクチャが、現実のプロダクトやサービスに適用できるほどまで洗練されたサービスとなってきました。
このパラダイムシフトは、これまでのウェブアプリケーションの開発・運用スタイルを大きく変える可能性があります。
もともとはMicroservicesの文脈で語られていたことです。サービスを小さく保ち、開発を容易にし、デプロイを気軽に行いやすくなっただけでなく、サービス運用におけるインフラ障害への対応責任をクラウドサービスに任せしてしまうことで、サービス開発チームの中に専門のインフラエンジニアを割り当てなくとも開発・運用が行えるような環境となってきました。
これは本当に大きなインパクトを持ちます。いかにチームが小さくなろうとも、インフラというステークホルダは、ビジネスサイドとの折衝からはどうしても遠い立場です。そのインフラとの情報共有が不要となり、よりビジネス開発に割く時間が増えるという未来が近づいていると思います。
今後はクラウドサービスをいかに上手く組み合わせて要求を満たし、かつスケールさせていくかにフォーカスが移ろうとしています。そのような中でオンプレミス環境におけるMySQLなどのデータストアをクラウドストレージ環境に円滑に移行させるようなソリューションなどが登場してきて、移行がより進むのではないかなと予想しています。
APIのエラー表現
長らくRESTful APIのエラー表現とはHTTP Response Status Codeでした。しかし、これが多様なビジネスロジックにおけるエラーを表現するにはあまりに語彙不足であるのは周知の事実でした。そのため、各サービスで独自のエラー表現が量産されることとなり、同じ手法でエラー表現を記述し、それを利用するといった環境ができていませんでした。
そのような中、RFC7807 - Problem Details for HTTP APIsというエラー表現をJSON/XMLで記述するための仕様が2016年5月に登場しました。この仕様はStatus Codeに加えて、本文中の属性としてtypeを与えることによって、同一のStatus Codeの異なるエラー表現を可能にしました。今後はこのフォーマットが広く使われていくことが期待されます。
JSON Schemaのその後
JSON Schemaは公式サイトで説明されているとおり、JSON文書に注釈をつけて検証を行うためのSchema言語です。現在普及しているのはv4と呼ばれるバージョンですが、2016年10月にv5仕様の候補がIETFのdraftとなりました。
JSON Schema仕様は次の3つから構成されます。
Core仕様ではv5仕様全体の概観を提供しつつ、プリミティブ型の定義やインスタンスの等価性の定義、スキーマの拡張方法など全体として共通の定義が行われています。全体としての変更は小さいように見えますが実はかなり影響の大きい変更が提案されています。詳しくは紹介しませんが、次の2つの変更が大きいと考えています。
idキーワードの挙動の変更$refキーワードがJSON Referenceではなく、JSON Schemaの独自定義に変更
Validation仕様では、大きな変更はありません。
最後のHyper Schemaでは、多くのLink Relationが削除されたり非推奨になりました。またmethodプロパティにもgetかpostしか記述できなくなるなど、Linkに対する操作を明確に定義する方向性ではなく、あくまでRESTとして自明の操作を暗黙的に指し示すようなものに方向性がシフトしているように見受けられます。
このように、Core仕様では実装に大きく影響を与えるであろう変更が提案され、APIの記述言語としては貧弱になることから、この方向性ではv5の先行きはあまり芳しくないと予想しています。これからのdraftの積み上げに期待していきたいと思います。
Open API Initiativeの誕生
かつてSwaggerとして知られていたAPI設計、開発、ドキュメンテーション等のツール群を提供するためのAPI記述仕様を決めるために、GoogleやMicrosoftなどが参加したOpen API Initiativeが2015年11月に立ち上がりました。本格的な活動は2016年から始まったようで、現行仕様である2.0をベースに次期バージョンである3.0の検討が進んでいます。
JSON Schemaがvalidationルールを記載することによるリソース定義に主眼が置かれ、APIのインターフェースを定義するには貧弱な語彙しかなかったのに比べて、SwaggerはAPIリクエスト／レスポンスに対して詳細な記述をJSON/YAML形式で記述が可能な仕様になっています。大手が参画したことからSwaggerを導入する企業が増えた実感があります。
Swaggerの優れた点はデータ定義にはJSON Schema v4をそのまま利用した上で、足りない部分のインターフェースを明確に定義できる仕様になっているところです。したがって周辺ツール群も充実しています。例えば主要なものとして以下があります。
まずSwaggerの定義ファイルがある場合はSwagger CodeGenを用いて20以上のプログラミング言語のボイラプレートサーバーを生成できます。さらに40以上の異なる言語のSDKを生成します。 またSwaggerの定義ファイルからSwagger UIを通じて継続的に実装であるSwagger定義に追従したAPIドキュメントも生成できます。 Swagger定義ファイルを作成する手助けとしてSwagger Editorが存在します。
このようにSwaggerはAPI開発をドライブさせるためのAPI記述仕様であり、また周辺ツールはよりMicroservicesの文脈の一つであるサービス単位の小さなチームによる開発を促進していくものになるでしょう。
すでにAWS API Gatewayの定義に対してSwaggerの定義をimport/exportできることから、API開発は設計を中心として実装のありとあらゆるところまで同期したスタイルになっていくと考えられます。
終わりに
2016年で筆者が注目したAPI界隈のトピックの表層をざっと振り返ってみましたが、2017年はどのような展開を見せるでしょうか。
サーバーレスとフルマネージドサービスの流れは最早止まらず、その流れだけでも開発においてのプログラマやエンジニアの役割が問われるような年になっていくのではないでしょうか。そこに加えてSwaggerのような仕様及び周辺ツールが整ってくると、いよいよ枠組みを構築しさえしてしまえばCI/CDを、Microservices全体を貫き実現できるようになっていくと考えられます。AIの発達に伴う雇用の未来が変わると予想されているように、API界隈の技術革新でも専門分野に対する役割の変化が訪れるはずです。
新春早々うかうかできない結びとなってしまいましたが、エンジニアとは学び続けなければならない宿命です。今年も頑張りましょう。
