テクノロジーが一般に普及するためには、それを支えるイノベーションが必要です。例えばiPadを考えてみましょう。2010年にiPadがリリースされる前からタブレットという概念は存在していましたが、AppleがiPadで成功できたのは、当時のWi-Fi接続の普及が一因でした。

接続性の普及がタブレットを現実のものにしたように、記述形式の普及がAPIを商業的に成功させます。OpenAPI Specification (OAS)は、RESTfulインターフェースの世界的標準記述形式として登場しました。OpenAPI Specificationは、人間の理解しやすく、機械が読み取れるREST APIのインターフェースです。OpenAPI Specificationは、APIが何をするのか、つまりAPIが公開するリソースとその対応するリクエストとレスポンスを記述します。

この形式により、APIの内部関係者と外部の利用者との間のアクセス性とコラボレーションが向上しました。簡単に言えば、OpenAPI SpecificationはAPIの構築と提供の方法を変えました。

OASはLinux Foundation傘下のOpenAPI Initiative (OAI)によって管理されています。Linux Foundationの傘下にあるオープンなガバナンス構造として、OAIはベンダーに依存しない記述形式の作成、進化、促進に注力しています。

今年のAPI Strategy & Practice Conference、APIStrat 2017で、OAIの技術運営委員会（TSC）のメンバーであるダレル・ミラー氏とお話しする機会がありました。ダレル氏は、OASプロジェクトの現状と、業界が最新バージョンの仕様であるOAS 3.0をどのように受け入れているかについて貴重な洞察を共有してくれました。

OAS 3.0の現状

OAS 3.0は今年初めにリリースされましたね。これまでのフィードバックはいかがですか？

これまでのフィードバックは非常に好意的です！仕様をもう少し読みやすくするために、構造をきれいに整理しました。OAS 3.0で行った変更の一部がHTTPの動作とより密接に連携し、多くの開発者がその能力を最大限に引き出すことができたのを見て、嬉しく思っています。

WebHooksとLinksの機能に興奮している人々が多くいます。Linksの機能は本当に興味深いワイルドカードでした。それを使ってたくさんのクールなことができる可能性があると思います。多くの人が、私たちがハイパーメディアを具現化しようとしたと誤解していますが、特にハイパーメディアのバックグラウンドを持つ私にとっては、Linksについての人々との会話は常に興味深いです。

OpenAPI Spec 3.0は、静的な設計原則を使用してAPIを構築し、API内の操作とリソース間の関係を定義したいと考えている企業にとって、真のニーズに応えています。間違いなく、インフラストラクチャの重要な要素となっています。

OAS 3.0は、APIのドキュメント作成も大幅に改善する可能性を秘めていると思います。なぜなら、突然、APIを介したフローを記述する可能性が生まれたからです。シナリオはAPIを記述し文書化するはるかに良い方法であり、Linksはフロー間のドキュメント自動化を現実のものにする道を進むのに役立ちます。人々がそれに関して構築するツールを見るのが楽しみです。

個人的には、よりリッチなAPIドキュメントのユースケースと、リソース間のより良い関係処理を見たいと思っています。

APIを使うにはどうすればいいの？どこから始めればいいの？150ものリソースがあり、長いアルファベット順のリストがあり、パス構造を見て、それが何を意味するのかを判断し、そこから推論しなければなりません。しかし、もし実際に消費者に「ここが開始点であり、ここから情報を要求できます」と伝えることができれば、話は別です。

そのパスをたどる必要はありません。それらのエンドポイントにジャンプすることもできますが、少なくともAPIがどのように構成されているかを理解するためには、APIの構造に意味が大幅に追加されます。

採用は、あらゆる技術的取り組みの重要な要素です。OAIはOAS 3.0についてどのように教育し、情報を広めているのでしょうか？

ツールのサポートがまだ成熟していない段階で、あまりに大規模なプッシュを早期に行うべきではないと思いますが、これまでの採用状況は素晴らしいです。OASが大規模に採用される唯一の方法は、より多くのツールのサポートを得ることだと認識しています。GitHubプロジェクトには、OAS 3.0をサポートするすべてのツールをリストした実装ページがあります。このリストが日々増えていくのを見るのは非常にエキサイティングです。

OASを取り巻くツールに関しては、RubyやNodeJSから.NETやJavaScriptまで、さまざまな技術にわたって広がりが見られます。

マーケティング活動をさらにサポートするため、OASの認知度を高めるマーケティングおよびブランディング会社と契約しました。擁護活動についても検討しましたが、OASが提供するすべての機能をサポートするための適切なツールがすべて揃っていることを確認する過程にあるため、まだ少し時期尚早だと思います。

APIStrat 2017はOAIが後援する最初の主要イベントでした。今年のカンファレンスの特徴は何でしたか？

今年のAPIStratでは、OpenAPIへの重点が明らかに高まっていました。これは、過去12ヶ月間に仕様の新バージョンがリリースされ、API分野のすべての関係者のコンセンサスが、OpenAPIがRESTインターフェースの標準記述形式であるという点でようやく固まったからだと期待しています。API記述の価値は誰もが知っており、どの形式が最適かという議論はもうやめて、実際にエコシステムにますます多くのツールを投入し始めることができると思います。

仕様とツールの進化

さまざまな組織がOAIに深く関与している中で、これが仕様の進化プロセスをどのように強化しましたか？

それは全く大きく変わっていません。OAIは、コミュニティ内のすべての声が聞かれるように設計されました。加盟企業が組織に参加する場合、それは基本的に、OASの進化に影響を与えるのではなく、OASを支持するという公的な声明を出していることになります。OAIのメンバーシップは、仕様自体の構築の技術的側面とは完全に独立しています。

APIに関して関心のあるコミュニティの誰もが、好きなだけ貢献できます。仕様に貢献するためにメンバーである必要はありませんし、仕様を読んで消費し、恩恵を受けるためにメンバーである必要もありません。

業界企業がOAIに参加することは、勢いをつけ、分野での認知度を高め、OASの信頼性を確立する上で素晴らしいことです。しかし、技術的な観点からは、直接的な相関関係はありません。技術的な観点から重要なのは、より多くの人々を参加させることです。私たちは、より多くの中心的な人々を運営委員会に参加させることに注力するつもりです。すでに多くの人々がプロジェクトに extensively に貢献しており、これらの人々を推薦し、運営委員会に参加するよう招待することを望んでいます。これにより、彼らは仕様に何が入るかについてもう少し発言権を持つことができ、より多くのコミュニティメンバーに働きかけて、より多くの意見を得ることができます。

より多くの人々が貢献できるように、OAS 3.0の完成後、しばらく時間をかけて組織の整備を行い、ガバナンス体制を整えました。私たちは、貢献したい人々に推奨するプロセスを明確にするために、開発者ガイドラインに取り組んでいます。

仕様のオリジナルバージョンであるSwagger Specificationは、存在する多数のツールのおかげで非常に人気がありました。今後、OAIはより多くのベンダーと提携する計画はありますか？

私たちは常に、より多くの人々がツールを構築することを奨励するためにできる限りのことを行っており、OAIのメンバーの中にはツールの構築を進めている人もいます。OAIの役割と責任とツールの間にはかなり厳格な区別があります。私たちは仕様のガバナンスのみを担当しています。私たちは、公式組織が独自のツールを持つという事業には関わりたくありません。すべてサードパーティのツールであり、私たちは仕様を作成する事業にのみ従事しています。

これまでのところ、ツールの有機的な開発が企業から行われているため、人々を説得してツールを構築する必要はありませんでした。その多くは、既存のエコシステムにあるツールの更新に過ぎません。仕様を完成させ、人々がそれを吸収し、3.0に移行する価値を実証する時間が必要だっただけです。

ウェブサイトで公開されたブログ記事で、最初はOASに懐疑的だったと述べられていましたね。最終的にOASに携わることになるとは思っていましたか？

いいえ、OAIに入るとは夢にも思いませんでした。パネルでも言いましたが、技術的な観点からアーキテクチャパターンの正しさではなく、それが実生活の人々のワークフローに与える影響が重要です。私のブログ記事をご覧いただければわかるように、私はハイパーメディアの擁護者でしたし、今もそうです。

OASを使用して静的に設計されたAPIを使用すると、ドキュメントの足場を生成したり、クライアントを生成したりできるといった特定の利点が得られますが、柔軟性が失われるため、時間の経過とともに進化するためのバージョン管理戦略が必要になります。

静的設計と動的設計のトレードオフであり、ある時点で、たとえ進化可能性のパスではなくバージョン管理のパスを選択したとしても、大多数の開発者がより良いAPIを構築するのを助けるソリューションの一部になりたいと強く思うようになりました。

大多数の企業は、よりシンプルなアプローチを採用し、静的なAPI記述を持つことのメリットを活用しています。企業が非常に多くの価値を引き出しているこのイニシアチブに関わっていることを非常に嬉しく思います。OpenAPI Specificationの将来を導く上で、特定の落とし穴を避けるためにできることがあれば、喜んでその一部になりたいと思います。

OpenAPIは、将来的にGraphQLのような他のフレームワークやアーキテクチャをサポートするように進化すると思いますか？

HTTPは拡張性を持つように設計されており、その現れ方の一つがメディアタイプという形です。WebhooksはHTTPモデルに自然に適合するため、素晴らしいです。

GraphQLは、非常に自然にメディアタイプになりうる一連のものを定義しています。クエリのメディアタイプ、構造化された応答のメディアタイプなど、独自の型システムを持っています。既存の型システムがニーズを満たさない場合は素晴らしいことです。ウェブは、リクエスト、階層構造で記述されたリソース、完全に独立して送り返すことができるペイロードの間で、非常に優れた関心の分離があるため、大成功を収めてきました。

OASができることに話を戻すと、もし何らかのアーキテクチャスタイルが、HTTPの上にレイヤーを重ねるのではなく、HTTPにうまく適合するように構築されていたとすれば、それはOASに適合します。イノベーションや、人々が何かをすること自体は好きです。GraphQLは非常にうまくそれに適合し、既存のすべての技術と並んで機能したはずです。私が本当に望んでいるのは、HTTPエコシステムにもっと自然に適合する方法でそれを構築することです。

OASに適合すると考えられる唯一の大きなスタイルは、操作をリクエストボディの一部として実質的にトンネリングするRPCタイプのAPIです。これはまだ私たちにとって課題です。なぜなら、私たちはパスを使用して操作を識別するからです。操作をパス以外の何かで識別する方法について、私は何度も頭の中で議論してきました。例えば、OAS 3.0では、活用できる新しいランタイム式があります。それがどのように機能するのかはまだ分かりません。なぜなら、その場合、同じランタイム式を持つ多くの操作が存在することになるからです。それらの操作を一意に識別するために、異なる操作IDを持つことができるかもしれませんが？しかし、問題は、その時点でHTTPの動作方法からあまりにも離れてしまうのではないかということです。

そこには本当に興味深い議論があります。特に、誰もが価値を見出さないようなもので仕様を汚染し始めることなく、サポートできる範囲をどのように広げるかについてです。そのような隣接するRPC的なことを始めると、なんだか気持ち悪いと感じるかもしれませんが、さまざまな方法でAPIを設計したい人々をサポートする方法を見つけたいと強く願っています。

OASがサポートしたい新機能はすべてHTTPの動作に適合する必要があると述べられましたね。これらの機能の使いやすさも考慮されていますか？

採用にとって不可欠な要素ですよね？トニー・タム（オリジナルのSwagger Specの作成者）がその多くを仕様に組み込んだことに感謝しています。彼は常に、過剰に設計されているものや、エンドユーザーにとって複雑すぎると思われるものに対しては異議を唱えていました。

今では、フルタイムの開発者ではない人々もAPIの設計と構築を始めています。そのため、使いやすい記述形式を持つことが極めて重要になっています。実際、OpenAPIのミートアップで、ビジネスアナリストやプロダクトマネージャーといった、経験豊富な開発者ではない人々とも話しました。彼らはAPIの実装について最適なアイデアを持っているわけではないかもしれませんが、APIがカバーすべきビジネスケースのシナリオは理解しています。

まとめ

この会話の最後に、API分野で今後最も楽しみにしていることを教えていただけますか？

OAS 3.0を使ったリンクとドキュメントで人々が何をするのかを見てみたいです。APIドキュメントは信じられないほど難しく、苦痛なレベルに達することもあります。私よりもはるかに優れたテクニカルライティングスキルとUI知識を持つ誰かが、私たちがOASで構築したものを活用し、シナリオベースのドキュメント足場ジェネレーターを作成してくれることを願っています。

生成されたドキュメントには限界がありますが、シナリオベースの足場は、大量の消費可能な情報を生成する際の単調さを取り除くことができます。それが私が最も興味を持っていることの一つです。

そうすれば、生成されたものの上に付加価値を付け加えることができます。間違いなく興味深い分野であり、将来に非常に期待しています。

OpenAPI 3.0を使い始めることに興味がありますか？無料のトレーニングをご覧ください: OpenAPI 3.0と、それがSwaggerの未来にとって何を意味するか