REST vs RPC: API設計における2つの考え方

新しいサービスのAPIを設計しているとします。HTTPの動詞を使ったリソース中心のモデルにすべきでしょうか、それともクライアントが直接呼び出すプロシージャを公開すべきでしょうか?これは単なるプロトコルの選択ではなく、システムのインターフェースをどう考えるかという根本的な決定です。

REST vs RPC API設計は、2つの技術ではなく、2つの異なる思考様式を表しています。それぞれのアプローチがどこで輝くか(そしていつ組み合わせるべきか)を理解することで、将来のアーキテクチャ上の問題を回避できます。

核となる考え方の違い

RESTはリソースで考えます。名詞(ユーザー、注文、製品)と固定された動詞(GET、PUT、DELETE)があります。URLは何を操作するかを識別し、HTTPメソッドがどのようにを示します。

RPCはアクションで考えます。引数を伴って呼び出すプロシージャ(createUser、processPayment、generateReport)があります。焦点は何をしたいかであり、何を操作するかではありません。

どちらが本質的に優れているわけではありません。それぞれ異なる問題をうまく解決します。

// REST: リソース指向
GET /users/123
PUT /users/123 { "name": "Alice" }

// RPC: アクション指向  
POST /rpc/getUser { "id": 123 }
POST /rpc/updateUserName { "id": 123, "name": "Alice" }

明確にすべき一般的な誤解

RESTは「単なるJSON CRUD」ではありません。 真のRESTには、ステートレス性、キャッシュ可能性、階層化システムなどの制約が含まれます。ほとんどの「REST API」は実際にはリソース指向のURLを持つHTTP APIです—それで問題ありませんが、同じものではありません。

RPCは時代遅れではありません。 gRPCやConnectのような最新の実装は、Google、Netflix、そして数え切れないほどのスタートアップで重要なインフラを支えています。gRPCはHTTP/2とHTTP/3上で動作し、Kubernetes Gateway APIで標準的なルーティングサポートがあります。

HTTP API vs RPCは二者択一ではありません。 多くの本番システムは、エッジ(パブリックAPI、ブラウザクライアント)でRESTを使用し、内部(サービス間通信)でRPCを使用しています。このハイブリッドパターンはますます一般的になっています。

実際に重要な実用的なトレードオフ

キャッシングとHTTPツール

RESTのリソースモデルはHTTPキャッシングと自然に連携します。GET /products/123のレスポンスは、特別な設定なしにCDN、ブラウザ、プロキシによってキャッシュできます。

RPCは通常すべてにPOSTを使用するため、HTTPインフラはデフォルトでキャッシュ不可として扱います。RPCをキャッシュ可能にすることもできますが、明示的な設計作業が必要です。

型安全性とコード生成

gRPC(Protocol Buffersを使用)やConnectのような最新のRPCフレームワークは、強い型付けと自動クライアント生成を提供します。サービスを一度定義すれば、TypeScript、Go、Pythonなど向けのクライアントを生成できます。

RESTにはOpenAPI(現在バージョン3.2、3.1で完全なJSON Schemaアライメントを導入)があり、同様のコード生成を提供します。しかし、型付けはネイティブというより後付けのように感じることが多いです。

ストリーミングとリアルタイムデータ

gRPCは双方向ストリーミングをネイティブにサポートします。RESTには回避策が必要です—Server-Sent Events、WebSocket、またはロングポーリングです。

ブラウザクライアントの場合、RPCは通常gRPC-Web、ConnectのHTTPフレンドリーなプロトコル、またはJSONトランスコーディングを通じて動作します。これらは複雑さを追加しますが、純粋なRESTでは実現できないストリーミングパターンを可能にします。

エラーハンドリング

REST APIは、標準化されたエラーレスポンスのためにRFC 9457(Problem Details)を採用することが増えています。RPCフレームワークには独自のエラーモデルがあります—例えばgRPCのステータスコードです。

どちらも機能します。重要なのはシステム内での一貫性です。

何を選ぶべきか

RESTを選ぶべき場合:

• 未知のクライアントが利用するパブリックAPIを構築する
• キャッシングがパフォーマンスに重要
• 既存のHTTPツールとの最大限の互換性が必要
• 操作がリソースに対するCRUDにきれいにマッピングされる

RPCを選ぶべき場合:

• 内部のサービス間APIを構築する
• ストリーミングまたは双方向通信が必要
• 強い型付けとコード生成が優先事項
• 操作が本当に手続き型(「サーバーを再起動」「分析を実行」)

両方を使用すべき場合:

• パブリック向けAPI(REST)と内部マイクロサービス(RPC)がある
• システムの異なる部分に異なる要件がある

ハイブリッドの現実

最新のAPIアーキテクチャパターンのほとんどは、1つのアプローチだけを選択しません。典型的な構成では、外部の利用者向けにAPIゲートウェイを通じてREST APIを公開しながら、パフォーマンスと型安全性のために内部サービス間でgRPCを使用します。

これは妥協ではありません—各コンテキストに適したツールを使用しているのです。

まとめ

制約から始めましょう。このAPIを誰が利用するのか?どのような操作をサポートする必要があるのか?キャッシングはどれほど重要か?ストリーミングは必要か?

REST vs RPCは「どちらが優れているか」ではありません。リソースかプロシージャか、どちらの考え方が問題により適合するかです。多くの場合、答えは両方です。

よくある質問

Truly understand users experience

See every user interaction, feel every frustration and track all hesitations with OpenReplay — the open-source digital experience platform. It can be self-hosted in minutes, giving you complete control over your customer data. . Check our GitHub repo and join the thousands of developers in our community..