gRPC、OpenAPI、およびRESTの理解とAPI設計での使い分け（2020）

 (cloud.google.com)
1 ポイント 投稿者 GN⁺ 2025-01-24 | 1件のコメント | WhatsAppで共有

API 管理

gRPCとREST: API設計におけるgRPC、OpenAPI、RESTの理解と使いどころ

  • API設計モデル: API設計では主にRPCとRESTの2つのモデルが使われる。現代のAPIの大半はHTTPプロトコルを基盤として実装されている。
  • gRPC: HTTP 2.0をトランスポートプロトコルとして使用するRPC API実装技術。Googleなどでは、RPCとHTTPの考え方を組み合わせたAPIが多く使われている。
  • HTTPの3つの主要な利用方法:
    1. REST: クライアントはサーバーが提供するURLをそのまま使用し、URLの形式を理解する必要がない。
    2. gRPC: HTTP/2を使うが、HTTPはAPI設計者に露出しない。
    3. OpenAPI: クライアントはURLパステンプレートを使ってAPIを呼び出す。

REST

  • 特徴: クライアントはURLの形式を理解する必要がなく、URLはAPI仕様の一部ではない。
  • 長所: 安定性、一貫性、汎用性など、Webの利点を備える。エンティティ指向モデルのほうがよりシンプルで理解しやすい。

gRPC

  • 特徴: HTTP/2を使うが、HTTPの詳細は隠蔽される。クライアントは手続きを呼び出し、パラメータを渡してAPIを利用する。
  • 長所: クライアント側のプログラミングライブラリを簡単に生成でき、性能が高い。

OpenAPI

  • 特徴: URLパステンプレートを使ってAPIを呼び出し、クライアントがURLの形式を理解する必要がある。
  • 長所: 標準的なHTTP技術だけでAPIにアクセスできる。クライアント側のプログラミングライブラリを生成できる。

gRPCとOpenAPIの比較

  • 共通点: どちらもRPCインターフェース定義言語（IDL）として利用できる。
  • 相違点: gRPCはHTTPの詳細を隠し、OpenAPIはHTTPの詳細を露出する。

RESTの長所

  • エンティティ指向モデル: よりシンプルで理解しやすく、時間が経っても安定している。

OpenAPIの使い方

  • パス定義: パスとHTTPメソッドを使ってAPIを定義する。

OpenAPIの長所と短所

  • 長所: RPCモデルに近く、プログラマにとって親しみやすい。HTTPリクエストにマッピングできる。
  • 短所: HTTPの詳細を設計するのに多くの労力が必要となる。

gRPCの長所

  • シンプルな実装: サーバー側の実装がシンプルで、クライアント側ライブラリも簡単に生成できる。
  • 性能: バイナリペイロードを使用するため効率的である。

gRPCの短所

  • 特別なソフトウェアが必要: クライアントとサーバーの両方に特別なソフトウェアが必要となる。
  • プロキシ機能の制約: HTTP APIとは異なり、プロキシで機能を拡張または変更しにくい。

結論

  • API設計の選択: REST、OpenAPI、gRPCそれぞれの長所と短所を考慮して選ぶ必要がある。
  • gRPC利用時の考慮事項: クライアントがgRPC技術を採用しなくてもよい場合や、内部APIである場合に有利である。

関連記事

1件のコメント

 
GN⁺ 2025-01-24
Hacker Newsのコメント

  • gRPCを学ばなければよかったと後悔している。デバッグと設定調整に多くの時間を費やした

    • gRPCは内部を隠してくれると言われるが、実際には多くのデバッグと設定調整が必要になる
    • Mavenプラグイン、HTTP2との互換性の問題、ファイアウォールの問題などで多くの時間を無駄にした
    • ドキュメントが不十分で、エラーメッセージを観測しやすくするのが難しかった

  • 長年APIを構築してきており、gRPCとHTTP/RESTを使ってきた

    • OpenAPIとRESTの違いを区別するのは奇妙だと思う
    • OpenAPIはHTTP APIの動作を文書化する方法であり、RESTful APIを表現できる
    • gRPCはProtocol Buffersをやり取りするRPCメカニズムである
    • gRPCは効率的だが、HTTPライブラリほど強力ではない

  • FAANGで働いた経験があり、内部サービスルーティングにgRPCが有用だと考えている

    • RPCプロトコルは大規模かつ高速な処理を可能にする
    • しかし、顧客向けやWeb向けであればgRPCは使わないだろう

  • 双方向ストリーミングをしない限り、gRPCは時間の無駄だと思う

    • さまざまな言語で実装されたサービス間でRPC呼び出しを行う際に、多くのミドルウェアが必要になる

  • gRPCを使ったプロジェクトで性能を理由に導入したが、JSON APIに切り替えた

    • gRPCの経験が不足しており、プロジェクトは複数の問題によって失敗した

  • connectrpcを使うことでgRPCの問題点を解決しつつある

    • buf.buildを通じて3rd party protoファイルを簡単に取り込める
    • SDK自動生成機能が非常に便利だ

  • gRPCはRESTより開発体験が悪いと考えている

    • 追加のツールが必要で、生成されたクライアントコードが複雑である

  • Roy Fieldingは、REST APIでは最初のURIと標準化されたメディアタイプだけ分かっていればよいと述べている

  • データセンター内でgRPCを使うのは好きではない

    • 性能がそれほど高くなく、オープンソースクライアントの品質が低い
    • WebベースのAPIではJSONの可読性を好むが、型の不一致の問題がある

  • gRPCはGoogleの外では扱いづらいと感じた

    • gRPC JSクライアントは重く、不透明だ
    • RESTのシンプルさに比べると、うまく設計されていないと思う