REST、gRPC、および GraphQL を使い分ける (パート 1)

マイクロサービスの普及により、ソフトウェアの世界では多くの新しい革新的なアプローチが生み出されています。しかし、期待するビジネス成果が一貫して得られる、堅牢で高品質な API の構築は複雑な作業です。マイクロサービスを採用する組織を対象とした最近の調査で、回答者の約 30% が最大の課題の 1 つとして「API の品質」を挙げているのも不思議ではありません。

API ベースのアプリケーションは多種多様です。API 形式ごとにそれぞれの長所と短所があり、どれを使うかは特定のアプリケーション要件に大きく依存します。

この 2 部構成のシリーズでは、API 開発で最も人気のある 3 つのアプローチ、REST、gRPC、GraphQL について紹介します。それぞれのモデルの長所と短所を比較し、アプリケーションに最適な API モデルを判断する方法を説明します。

REST
REST の長所と短所
REST のユースケース
gRPC
gRPC の長所と短所
gRPC のユースケース
まとめ

REST

REST (REpresentational State Transfer) は、現在最もよく使われている API アーキテクチャです。アプリケーションの状態を Web リソースで表現する REST では、それぞれの用途に対応した HTTP 動詞 (HTTP メソッドとも呼ばれる) を使用します。

POST: 新しいリソースを作成します。
PUT: リソースが存在する場合はリソース全体を更新し、存在しない場合は作成します。
DELETE: リソースを削除します。
PATCH: 既存のリソースを部分的に更新します。
GET: 既存のリソースを照会します。

REST の長所と短所

RESTful API は広く使用されており、ほとんどのアプリケーション開発者は RESTful API に馴染みがあります。REST は HTTP プロトコルの設計と密接に連携しているため、ブラウザーやその他の HTTP クライアントは RESTful API からのレスポンスをネイティブに理解できます。

しかし、REST は万能ではありません。これが、REST が唯一の API アーキテクチャでない理由です。RESTful API は、特にリソースが複雑な場合、レスポンスが肥大化する可能性があります。これは、GraphQL の人気が高まっている理由の 1 つです。また、非常に低電力のクライアントでは、REST は理想的とは言えず、gRPC のほうが魅力的です。

柔軟性の高い RESTful API 開発では、開発者が原則と標準を遵守する責任を負います。OpenAPI 仕様はこのための素晴らしいツールですが、RESTful API は本質的に自己文書化されていないため、積極的に遵守することが求められます。

REST のユースケース

ほかにやむを得ない理由がない場合、REST はおそらくアプリケーションにとって最適な選択肢です。特定のニーズのユースケースには GraphQL や gRPC のほうが適しているかもしれませんが、単に適切で堅実な API アプローチで構築したい多くの場合には REST が適しています。REST API は学習曲線が浅く、膨大なリソースのエコシステムと一般公開されている豊富な例を利用して学習できるため、デフォルトの選択肢として考慮すべきです。

gRPC

gRPC (Google Remote Procedure Calls) は Google によって設計および開発されました。

リモートプロシージャコールの一般的な概念を進化させた gRPC では、クライアントはリモートコンピューター上のメソッドを、そのシステムがローカルであるかのように直接呼び出すことができます。gRPC はプロトコルバッファー (または Protobufs) を利用して、テキストベースの JSON や XML ではなく、バイナリにシリアル化されたデータでタイプセーフなデータ転送インターフェイスを定義します。また、HTTP/1 よりも信頼性が高く、高速で効率良い HTTP/2 を利用しています。

gRPC API には、4 種類のサービスメソッドがあります。

Unary: クライアントはサーバーに 1 つのリクエストを送信し、サーバーは 1 つのレスポンスを返します。
Client-Streaming: クライアントはサーバーに一連のリクエストをストリーミングし、その後ストリームの終了を示すメッセージを送信します。サーバーは 1 つのレスポンスを返します。
Server-Streaming: クライアントは 1 つずつリクエストを送信し、サーバーは一連のメッセージをストリーミングしてレスポンスを返します。ストリームは、すべてのメッセージが送信されるか、クライアントが切断されるまで継続されます。
Bidirectional Streaming: クライアントとサーバーの間に接続が確立され、必要に応じてどちらかがメッセージを送信したり、接続を終了できます。

gRPC の長所と短所

gRPC はデータのシリアル化に Protobufs を使用することで、非常に軽量で高速な API を提供します。非常に軽量であるため、gRPC はクライアントの計算能力が限られている場合 (IoT など) によく使われます。このような場合、サーバーが負荷の高い処理を行います。

また、gRPC の言語に依存しないインターフェイスコントラクトの定義は、異なる言語で記述されたサービス間に優れた通信方法を提供します。gRPC の学習曲線は、REST ほど浅くはないものの、十分に許容できるものです。

gRPC は非常に効率的ですが、ブラウザーで十分にサポートされているわけではありません。また、サンドボックスで実験しながら学習するのは難しく、HTTP/2 の使い方も、経験の浅い API 開発者には馴染みのないものでしょう。

gRPC のユースケース

クライアントマシンのパフォーマンスを最大限に引き出す必要がある場合、gRPC は素晴らしい選択肢となりえます。このため、gRPC はスマートデバイス間の通信の促進に広く使用されています。サイズ、限られた計算リソース、リアルタイム機能の必要性から、IoT デバイスの動作は gRPC のパフォーマンスに依存しています。gRPC は、デプロイメントパイプラインツールやアプリケーションモニタリングシステムにも適しています。

まとめ

パート 1 では、REST と gRPC について詳しく取り上げ、API 開発環境における主な相違点を理解しました。パート 2 では、GraphQL について取り上げ、REST や gRPC との相違点を探っていきます。最後に、3 つの API モデルを比較し、あなたのチームの現在のユースケースに役立てる方法をまとめます。

Kong Enterprise の概要、価格、およびライセンス体系などの詳細は、こちらを参照してください。