コンピュータプログラムやサービスが互いに通信する方法として便利なのが、アプリケーションプログラミングインターフェース（API）です。この通信は通常、APIエンドポイントを介して行われ、クライアントが利用するプログラムに適用されます。
この記事では、APIを構築するための2つの一般的なアプローチとして、REST（representational state transfer）APIとWeb APIを比較します。
REST APIとは
よく誤解されることですが、REST APIはプロトコルではありません。どちらかと言えばアーキテクチャや設計であり、API開発で広く採用されています。GraphQLとRESTの解説記事で説明していますが、RESTはステートレスであるため、リクエスト間でデータやステータスが保存されることはありません。
RESTでは、HTTP通信を用いたアプリケーションの構築について、複数のアーキテクチャ上の制約が定義されています。
-
- クライアント/サーバーアーキテクチャ
- ステートレス
- 統一インターフェース
- キャッシュ
- 階層型構造
- コードオンデマンド
RESTは、他のAPIプロトコルやアーキテクチャに比べて使い勝手が良いのが特徴です。また、その他にも多くの利点があるため、APIを構築する多くの開発者にとっての優れた選択肢となっています。
- 多様なメッセージフォーマット：REST APIでは、データのシリアライズにJSONを使用することがほとんどですが、JSON、HTTP、プレーンテキスト、XMLなど、複数のメッセージ形式を使用できます。JSONはXMLに比べて軽量で、配列のサポートなど柔軟性が高く、解析が容易なため、SOAP（Service Object Access Protocol）のように主にHTTP上のXMLで動作するプロトコルよりも優れているとされています。
- HTTPメソッド：RESTは通常、その用途に応じて、データの取得やリクエスト（
GET,POST,PATCH,DELETE,PUT）のいずれかのメソッドと一緒に使用されます。これらのメソッドは、一般的なHTTPの成功/失敗を示すコードを返します。その他には、OPTIONS、HEAD、TRACEなどもあります。これらのメソッドはサービス間で一貫性がなく、プロバイダーによっては1つのメソッドしか実装していない場合もあります。 - 非結合型アーキテクチャ：RESTではクライアント─サーバー型のアーキテクチャが採用され、ロジックとその表示領域が分離されるため、複数の部位で干渉を引き起こすことなく、同時に作業を進めることができます。
- スケーラビリティ：REST APIはシンプルであるため、簡単に使用することができます。とは言え、規模を拡大する必要がある場合は、新しいエンドポイントを作成し、より複雑なロジックを組み込むことも可能です。
- キャッシュ性：RESTはステートレスですが、クライアント上のサーバーレスポンスをキャッシュすることで、冗長なリクエストの繰り返しを避けることができます。サーバーのレスポンスには、通常、キャッシュの実行方法に関する情報が記載され、クライアント側で一定期間リクエストのキャッシュを行います。
- セキュリティ：ほとんどの場合、RESTエンドポイントはHTTPSエンドポイントを介して公開され、すべてのAPI通信がTLS/SSLを使用した保護の対象となります。RESTは、OAuth2やJSON Web Tokens（JWT）など、その他の認証・認可スキームもサポートしています。
Web APIとは
Web APIとは言うなれば、HTTPでサーバーのリソースにアクセスするためのインターフェースです。Web APIは、JavaやASP.NETなど、さまざまな技術を使って構築することができます。Web APIでは、オープンソースのインターフェースを使用し、ブラウザ、スマートフォン、タブレット、パソコンなど、多くのクライアントエンティティを活用可能です。
Web APIは、キャッシュ、バージョン管理、コンテンツフォーマットに関連したプロトコル実装を手広く支援します。Web APIの実際の中身は、その構築方法によって、REST APIになることも、そうでないこともあります。Web APIは通常、スマートフォンやパソコンなどの複数デバイスでサービスを提供する分散型システムで力を発揮し、ウェブアプリケーションのクライアントサイド等で活用されます。
広く使われているWeb APIの例を2つ以下にご紹介します。
- Google API：YouTube動画をサイトなどのアプリケーションに埋め込むことができるYouTube API、JavaScriptやFlashなどのインターフェースを使ってGoogle マップをウェブページ上で表示することのできるGoogle Maps APIなどがあります。
- Twitter API：Twitter検索と連動するメソッドを提供するTwitter検索APIや、TwitterのコアデータにアクセスできるREST APIがあります。
Web APIは、システム間のやり取りを司るものです。API内のデータの流れは以下のようになります。
- クライアント端末が、ウェブサーバーにリクエストを送信
- ウェブサーバーがリクエストを受信し、処理した後、クライアントデバイスに送り返して実行
- 出力の内容がクライアント側のユーザーにレンダリングされる
Web APIの有益な機能としては、以下のようなものがあります。
- 軽量なアーキテクチャ：Web APIは、スマートフォンのような帯域幅の制限のあるデバイスで使用するのに向いています。
- メッセージヘッダ：Web APIには、コンテンツタイプ、セキュリティスキーム、キャッシュの扱い方などの情報を含む、メッセージヘッダ（メタデータ）が付されます。
- あらゆるデータ型をサポート：バイナリファイル（動画、画像、文書）、プレーンXML、JSON、HTMLなど、Web APIのボディはあらゆるデータ型に対応しています。
- リソース指向のサービス：Web APIでは、RESTアーキテクチャに準拠した方法でリソースを公開することができます。
- 設定とセットアップが簡単：Web APIのセットアップと実行は簡単です。
Web APIとREST APIの比較
では、この2つのAPIをより詳しく比較してみましょう。
構造の類似点
Web APIとREST APIには、構造上の共通点があります。その中身を見てみましょう。
- ステートレス：HTTPリクエストは単独で発生し、基本的にステートレスです。各リクエストに、それを完了するのに十分な情報が含まれます。複数のリクエストは、クッキーやセッションIDなどの共有される情報によってのみ互いに関連付けられます。状態の同期がないため、サーバーがクライアントのリクエストを追跡する必要がなく、複雑さを軽減し、パフォーマンスの向上も期待できます。また、同時に進行するリクエストは、複数のサーバーにまたがって拡張することが可能です。
- 階層型構造：APIのデプロイ、リクエストの認証、ストレージ操作が複数のサーバーにまたがって行われる、階層型構造をサポートしています。
- リソース指向：リソース指向のアーキテクチャでは、リソースはUniform Resource Identifiers（URI）に紐付けられます。Web APIとREST APIは、URIを介してリソースを公開するため、どちらもリソース指向です。
- キャッシュ性：RESTとWeb APIでは、呼び出すたびに同じ情報を返すクエリがキャッシュされます。例えば、エンドポイントでのOPTION呼び出しは、何度呼び出しても出力が同じなのでキャッシュ対象です。この特性は、「idempotence（冪等制）」と呼ばれ、データをキャッシュするかどうかを決定する良い判断基準になります。RESTでは常に冪等性が考慮されるのに対して、WebAPIではRESTほどではありません。冪等性のあるAPIコールとは─サーバー上で何かが変化する可能性があろうとも─何度呼び出しを行っても結果が変化しないものを指します。これのメソッドの例としては、GET、HEAD、OPTIONSなどがあります。
構造の違い
先に触れたように、Web APIとREST APIの構造には多くの共通点が見られますが、大事な違いも複数あります。
- クライアントサイドとサーバーサイドの連携：REST APIは疎結合のアーキテクチャを持ち、クライアント側とサーバー側で独立した開発が可能です。一方で、その他多くのWeb APIで、クライアントとサーバー間の変更がより細かく調整される傾向にあります。
- インターフェース：実装の仕方にもよりますが、REST APIは業界標準のインターフェースを使用する傾向があります。Web APIでは一般的に、APIプロバイダーによって、そのインターフェースが異なります。
通信手段
Web APIは（選択する具体的な手法によっては）あらゆる通信スタイルに柔軟に対応できるのに対し、REST APIでは、主にJSON、XML、プレーンテキストが使用されます。つまり、REST APIは、データベースに対するCRUD（Create, Read, Update, Delete）操作のようなテキストデータの伝達には適していますが、バイナリデータに対しては制約が見られます。
Web APIは全体として、より多くのメッセージ形式をサポートする傾向にあるため、音楽や動画のストリーミングのようなバイナリデータを必要とするサービスでは、一般的により優れた利便性を発揮します。
使用例
両APIフォーマットには、多くの場合、互換性がありますが、用途によっては長所・短所が明確になります。
- クラウドサービスやアプリケーション：REST APIはそのステートレスな性質から、クラウドサービスに広く使用されています。ステートレスなコンポーネントは、変更に対応するために、無理なく拡張したり再展開したりできます。複雑なコーディングの必要性が低いため、クラウドサービスや指標は通常、REST APIで公開するのが推奨されています。
- ストリーミングサービス：Web APIの多くにおいて、メモリや帯域幅に制約のあるデバイスを対象にしたアプリケーションバイナリデータのサポートが充実しており、加えてオーバーヘッドが少ないため、ストリーミングを必要とするサービスに向いています。
- データベース操作（CRUD）：Web APIよりもREST APIでCRUD機能を公開する方が一般的にシンプルで簡単です。
REST APIでは、単純な階層構造になっていないリソースへのアクセスや、そのリクエストの管理が困難になちがりです。これは、リソース参照にURIが使用されるという性質に関係しており、このような状況では、URIパス、クエリパラメータ、リクエストボディを操作する必要があり、結果的にRESTの目的を逸脱することになります。これを行うには、カスタマイズがしやすくURIレスポンスやリクエストヘッダのサポートが充実している他のWeb APIが一般的に好まれます。
非同期呼び出し（RESTアーキテクチャでは容易に実装できない）などの技術をサポートするWeb APIは、複雑なAPIの要件に対応する優れた選択肢です。
まとめ
Web APIとREST APIは、リソースの提供やHTTPを介した通信を行うアプリケーションを構築するのに使用されます。RESTが統一されたインターフェースに対するアーキテクチャ上の制約を明確化したものであるのに対し、Web APIは一般的に、実装次第でRESTfulになり得る（※注釈：RESTの制約を遵守しないかたちでの、REStfulな実装）概念です。
Web APIとREST APIはどちらも軽量で、多くの場面で互換性があります。REST APIに比べ、その他Web APIはカスタマイズの施された操作性とより多くのメッセージタイプを誇り、バイナリデータを扱うサーバーとクライアント間の複雑なインタラクションをサポートします。
また、Kinstaのアプリケーションホスティングサービスを利用すれば、APIプロジェクトの構築、テスト、出荷を素早くかつ効率的にクラウド上で行うことができます。
コメントを残す