コネクターを必要としないAPI開発を実現する「APIスキーマ」

システムを連携させるAPIとAPI記述言語が増えるに伴い、SOAPにとってのWSDLのような「APIスキーマ」が必要になってきた。なぜAPIスキーマが必要なのか。

公開 2020年08月12日 08時00分

更新 2021年10月27日 13時12分

著者

David Brown

[Computer Weekly]

印刷する連載新着通知を受け取る

　アプリケーション開発プロジェクトにデータベーススキーマの設計を伴うようになったのはいつ頃だったろう。クラウドのAPIにとって、最初のスキーマ方式が意味することとは何だろう。

　まずは基本に戻り、データベーススキーマについて考えてみよう。データベーススキーマとは、データベース内のテーブル、フィールド、オブジェクトなどの情報の関係性を定義するメタデータの集まりだ。スキーマはデータベースの定義を容易にするだけでなく、プログラマーがテーブル、ビュー、プロシージャなどを適切に構築するための指針となる。

　今度はAPIを考えてみよう。APIとは、ソフトウェア、サービス、プラットフォームなど、全く異なる2つのコンポーネントが要求応答メッセージを通じて相互にやりとりするためのインタフェースだ。データベーススキーマと同じようなスキーマがAPIにあれば、開発者にとってどれほど便利なことだろう。

SOAPから学んだ教訓

　Webサービスが登場した1990年代以降、さまざまな業界団体がアプリケーション統合の標準化に取り組んできた。SOAPは、Webサービスとやりとりする標準を作ろうという試みだった。

　しばらくの間、SOAPはWebサービス用の「全能」のメッセージングプロトコルだと考えられていた。SOAPの操作と入力のパラメーターはWSDL（Web Services Description Language）というスキーマでドキュメント化された。

　時間がたつにつれ、WSDLなしでWebサービスを考えるのは難しくなり、WSDLはSOAPの前提条件のようになった。さらに時間がたつとSOAPは徐々に冗長になり、使用時の負担が増えるようになった。

　SOAPの問題に対処し、速くて軽く、優れたWebベースアプリを求めて、開発者はRESTに注目した。RESTは「REpresentational State Transfer」の略だ。RESTはネットワークアプリケーション設計を支えるアーキテクチャで、HTTPなどのステートレス通信プロトコルを使用する。そのためRESTは使いやすく、柔軟性が高く、高速なのでAPIで非常によく利用された。RESTful API（RESTを実装するWebサービス）は、疎結合システムの効率的な救世主として幅広く受け入れられている。

APIスキーマの誕生

　APIを探索可能にするには、コードスニペットとSDKを使ってAPIをドキュメント化する必要がある。だがRESTには、SOAPにとってのWSDLのような、コンピュータが判読可能なドキュメントがなかった。

　APIを定義して記述するというニーズから、「RAML」「Blueprint」「Swagger」など、競合するAPI記述言語（API DL：API Description Languages）が作られた。これが、APIスキーマ誕生の経緯だ。

　API DLで作られたAPIスキーマは、人間もコンピュータも判読可能だ。APIスキーマには、RESTful APIでできる操作内容とAPIとのやりとりの方法を記述する。プログラミング手順を詳しく説明するのに役立つ仮想の取扱説明書のようなものだ。

　このスキーマはAPIを探索しやすく、使いやすくするだけではない。詳細に定義されたAPIスキーマがあることで、開発者はAPIドキュメントやクライアントSDKをコンピュータで生成できるようになる。

API DLにOpenAPIが登場した背景

　API DLの数が増え続けている状況で、「Swagger」仕様がOpenAPI Initiativeに提供され、業界大手によって「OpenAPI」という新しいオープン標準が制定されることになった。

　APIのコネクターが提供されているかどうかはiPaaS（Integration Platform as a Service）のベンダー次第だった。統合するAPIのコネクターがベンダーから提供されていなければ、開発者が取れる選択肢は非常に限られる。同様に、APIが変わるとベンダーがコネクターを更新するのを待たなくてはならなかった。

　OpenAPIをサポートしていれば、コンピュータが判読可能なAPIスキーマを取り込んでAPIの操作に必要なサービスを臨機応変に生成できる。