RESTful APIとは

最も一般的なAPIのタイプの1つは「REST」です。これは「RESTful API」と呼ばれることもあります。RESTful APIには多くのメリットがあります。最大の利点は、既存のプロトコルを活用するように設計されていることでしょう。ほぼすべてのプロトコルで使用できるので、RESTful APIの作成時にはソフトウェアやライブラリを新たにインストールする必要がありません。例えばWeb APIに使用する場合は、通常HTTPを利用します。

RESTful APIの利点として、その優れた『柔軟性』も挙げられます。データは、メソッドやリソースに縛られません。そのため、RESTful APIは「数種類の呼び出し処理」や「異なるデータ形式での返信」が可能です。さらに、ハイパーメディアを正しく実装することにより、構造的な変更も実現できるようになります。この『柔軟性』により開発者は、社内の要望を満たしつつ、お客様のニーズにも対応できるようになります。

これから構築するインテグレーションにとって「RESTful API」が最適なAPIのタイプなのかを評価するとき、考慮しなければならない6つの重要な制約が存在しています。

• クライアントサーバ：「クライアントとサーバは互いに分離し、それぞれ個別にアップデートすべきである」という考え方に基づいた制約
• ステートレス：呼び出し（call）はそれぞれ独立して実行され、各呼び出しには、それ自体を正常に完了するために必要なすべてのデータが含まれまれるという制約
• キャッシュ：大量の「着信」と「発信」の呼び出しを処理するため、リクエストのオーバーヘッドの増大に対処するため、キャッシュ可能なデータは保存するように設計すべきであるという制約
• 統一インタフェース：アプリケーションとモデル、アクションをAPIレイヤーと密結合させず、他に影響させることなくアプリケーションの変更や更新を可能にさせる制約（なお、サーバーからクライアントの切り離しの実化に、統一インターフェースがカギとなります）
• レイヤー化されたシステム：アーキテクチャの異なるレイヤーが連携して階層を構築することで、アプリケーションのモジュール化を採り入れるという制約
• コードオンデマンド：コードやアプレットをAPI経由で送信し、アプリケーション内で使用できるようにする制約

XMLに限定されているSOAPとは異なり、「RESTful API」はクライアントの要求に応じてXML、JSON、YAMLなどのあらゆる形式で返答することができます。RPCとも違い、開発者がプロシージャ名やパラメータの順序を把握する必要もありません。

「RESTful API」のデメリットの1つに、セッション内などで状態（ステート）を維持する機能が喪失することが挙げられます。これにより、プロジェクトに新しく参加した開発者が使いこなすまでに余計な時間が必要になってしまいます。

インテグレーションを計画する際に、上記の「RESTful API」の6つの制約条件を理解した上で、その機能を設計することが重要となります。