APIコミュニティの主要メンバーが参加! APIスペックにフォーカスした「API Specifications Conference 2019」レポート

連載 :

イベント・セミナー2019

2019年12月24日(火)

はじめに

2019年10月15～17日、Linux Foundation主催による「API Specifications Conference 2019(ASC)」がカナダのバンクーバーで開催されました。昨年まで開催されていた「API Strategy & Practice(APIStrat)」を引き継ぎ、よりクリティカル、かつ強い注目を集めるAPIスペックにフォーカスしたカンファレンスになりました。

APIスペックとは、APIの仕様そのもの、またはAPIの仕様の記述方法を定義した規格を指します。現在最も有名なAPIスペックとしては、REST APIのAPIスペックであるOpenAPIがあります。本イベントには、例年APIコミュニティの主要人物が集まり、今回もRed HatのSteven Willmott(3scaleの創業者)、MicrosoftのDarrel Miller(OpenAPIのメンテナ)、GoogleのTim Burks(Swift gRPCのメンテナ)、Marsh Gardiner(OpenAPIのメンテナ)、PostmanのKin Lane(APIエバンジェリスト)、Progressive IdentityのMehdi Medjaoui(APIdaysの創業者)、AsyncAPIのFran Mendez(AsyncAPIの創業者)を筆頭に、APIコミュニティの主要な方々が参加され、カンファレンスは昨年同様活気にあふれていました。参加者は180名ほどでした。

今回、筆者は「What API Specifications and Tools Help Engineers to Construct a High Security API System?」という題目で発表しました。本記事では、筆者が参加したセッションの模様をダイジェストで紹介します。

AsyncAPIの台頭

今回のカンファレンスでは、AsyncAPIの躍進が目に付きました。AsyncAPIは、event-driven APIを記述可能なAPIスペックです。OpenAPIのadaptationとしてスタートしたため、OpenAPIと酷似する点が多々あります。依然としてAPIの分野ではREST APIおよびOpenAPIが主流なのは変わりませんが、AsyncAPIは、今回のカンファレンスでOpenAPIに次ぐAPIスペックの2番手の1つにまで一気に上り詰めた感がありました。これは、関連するセッション数を見ても明らかで、他のAPIスペック(例えばGraphQLやgRPC)が前年度のAPIStratと比較し、関連するセッション数は大方横ばいなのに対し、AsyncAPIは0セッションから9セッションにまで関連するセッション数が増えました。IDCやGartnerが「2020年までにAPIの50%はevent-drivenになる」と公言していることもあり、event-driven APIのAPIスペックの筆頭であるAsyncAPIに注目が集まるのは自然なことかもしれません。

初日に行われたワークショップの1つでは「Building Event-driven Architectures with AsyncAPI, Kafka, and Serverless Functions」と題し、AsyncAPIを作ったFran MendezがUberのようなRiderアプリを実際にevent-drivenアーキテクチャで作る方法を紹介しました。OpenAPIにおけるSwagger EditorのようなものであるAsyncAPIのplaygroundを使ってAPIスペックを作り、そこから各種コードを生成して動作を確認していました。登場人物はuser (車に乗る人)とdriver (車を運転する人)とcontrol panel (このシステムのメインで、メッセージの中継や各種ロギングを担当する)の3つです。フローは、以下のようになります。

userがride_requestedというAPIを叩くと、すべてのdriverに(control panel経由で)通知が行く
その通知を見て、driverがride_acceptedというAPIを叩くと、control panelに通知が行く
control panelがride_assignedというAPIを叩くと、userとアサインされたdriverに通知が行く

例えば、ride_requested APIはAsyncAPIでは以下のように定義します。このAPIはuserが叩き、driverは事前に申し込むことで、その情報をサブスクライブしてもらうことができます。

asyncapi: 2.0.0
info:
  title: Users API
  version: '1.0.0'

channels:
  ride_requested:
    subscribe:
      message:
        payload:
          type: string
          example: I want a ride!!!

各コードの生成にはAsyncAPI Generatorを使用しました。テンプレートも多々用意されており、またコード生成の精度も高く(手直しに時間を要している様子もなく)、コード生成機能には優秀さを感じました。Riderアプリのようなユースケースに対するevent-driven API(ないしAsyncAPI)の有効性が十分に示されたワークショップでした。

気になるのはセキュリティの部分です。ワークショップでもセキュリティに関して質問がありましたが、公式ドキュメントにも以下のような記述があり、エンタープライズユースでどのようにセキュリティを担保するのかが課題の1つです。

Traditionally, message brokers are infrastructure pieces that serve an internal purpose and they’re not exposed to the public. That’s why their security mechanisms are also simpler than what we’re used to with REST APIs.
(従来、メッセージブローカーは内部利用目的のインフラ部品であり、一般に公開されていません。そのため、メッセージブローカーのセキュリティメカニズムは、REST APIのセキュリティメカニズムよりも単純です。)

AsyncAPIは、まだノウハウが乏しく、上記のようなセキュリティの課題も存在するため、エンタープライズ適用には多数のチャレンジが予想されますが、event-driven APIのAPIスペックの筆頭として、今後の動向に注目していきましょう。

GraphQLの汎用化

GraphQLはクエリを用いるAPIスペックで、高いパフォーマンスやレスポンスの厳密性を売りにしています。GraphQLはRESTの性能ボトルネックを解消するものであり、FacebookやGitHubといった超高スループットが要求されるサービスにのみ有効である印象でしたが、今回のカンファレンスではGraphQLが使いやすく親しみやすいものになったという印象を受けました。

その理由として、まずリファレンスが非常に充実してきたことです。これにより初心者でもかなりとっつきやすいものになり、周辺ツールも確実に増えてきました。そのおかげもあり、MuleSoftのMatt McLartyによる「Overcoming RESTlessness」というセッションでも紹介されていました(図1)が、「JavaScriptウェブアプリケーションならGraphQL」といった一定の支持を獲得できたように思います。

図1：各APIスペックの棲み分け
(当日の資料より引用)

2日目には、GitHubのMarc-Andre Girouxにより「GraphQL & Caching: The Elephant in the Room」という題目でGraphQLが苦手とするキャッシングについて解説がありました。

キャッシングにはサーバ側とクライアント側がありますが、GraphQLが苦手とされているのはクライアント側のキャッシングであり、Freshness (キャッシュ内リソースの有効期限の設定、Cache-Control: max-age=60のような形でサーバが指定する)とValidation (リソースが変更されたかどうかの確認、Last-ModifiedやETagを使う)の2つで成り立つ、いわゆるHTTPキャッシングです。GraphQLの場合はクエリが頻繁に変わるため効率的にValidationを行うことが難しいケースが多く、またGETメソッドを使わなくてはならない点やGETメソッドのクエリパラメータにサイズ制限がある点が、GraphQLでキャッシングをする際の大きなチャレンジとなっています。

一方、CDNのような共有キャッシュ/ネットワークキャッシュに関してはFastQLのようなサービスもありますが、実現が非常に難しいことには変わりありません。また、RFC-7234に下記のように記載されている通り、共有キャッシュを使うとAuthorizationヘッダが使えないという点にも注意が必要です。

the Authorization header field (see Section 4.2 of [RFC7235]) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see Section 3.2)
(レスポンスが明示的に許可しない限り、キャッシュが共有されている場合、Authorizationヘッダフィールドはリクエストに表示されません)

発表者のMarc-Andreは、頻繁に「GraphQLはキャッシングができないわけではない」と繰り返していました。ただ、図2にもあるように、キャッシングが有効なユースケース(つまり認証なしのケースや、めったにデータが変更されないケース)にGraphQLが適さないことが多いため、キャッシングを採るかGraphQLを採るかは、そのトレードオフをよく吟味する必要があるとのことでした。

図2：GraphQLとキャッシング
(当日の資料より引用)

このセッションに代表されるように、本カンファレンスでは、GraphQLのセッションの内容がただGraphQLの良さをアピールするのではなく、一歩進んでGraphQLの上手な使い方や課題解決策を提案するような内容になり、GraphQLが認知され使われるようになってきたという傾向を示しているように感じました。

APIセキュリティの現在

現在、APIを公開するシステムが増えている中で、APIを公開して情報漏えい等の危険にさらされないようにするためのAPIセキュリティの重要性が増しています。APIスペックの分野でもセキュリティは重要な観点の1つで、セキュリティに纏わるセッションは毎年注目を浴びています。

3日目には、42CrunchのPhilippe Leothaudにより「Security in OpenAPI Specification」という題目でOpenAPIにおけるセキュリティについて解説がありました。2018年10月9日にリリースされた最新のOpenAPI 3.0.2では、Security Scheme Objectを用いてOAuth 2.0の各種フローやOpenID Connectを定義できます。またSecurity Requirement Objectを用いて、各リソースのスコープを定義できます。

一方、まだOpenAPI 3.0.2ではカバーできていないものとして(図3)、MTLS(クライアント証明書を使った相互TLS認証)、PKCE(認可コード横取り攻撃を軽減する機能)、Token Binding(トークン横取り攻撃を軽減する機能)などが挙げられました。MTLSはOpenAPI 3.1で入る予定とのことです。

図3：OpenAPI 3.0.2でカバーされていないセキュリティ項目
(当日の資料より引用)

筆者も、3日目に「What API Specifications and Tools Help Engineers to Construct a High Security API System?」と題目で発表しました(図4)。PKCEやOAuth MTLSのような高セキュリティ機能を有する周辺ツールが世の中に出回っていないので、高セキュリティAPIシステムを構築したときのテスト用にツールを自作したという内容でしたが、メイン会場に100名ほど集まりました。

図4：筆者の発表の様子

おわりに

昨年と同様、今回も日本人の参加は2、3人と少なく、まだまだ国内におけるAPIスペックの注目度は低いように感じました。APIスペックは、特にサービス(API)デリバリーのアジリティを考えたときに欠かせない要素の1つであり、今後、より重要度が増していくと考えます。日本でもAPIスペックの分野を盛り上げていきましょう!

API Specifications Conference 2019