gRPC と REST: gRPC、OpenAPI、REST と、API 設計でそれらをいつ使用するかを理解する

このようなパスを定義する API は、API のさまざまな場所で {petId} の値をクライアントに公開し、クライアントは {petId} 値 (および他の値) を URL に変換するために適切なパス定義を使用する必要があります。 HTTP リクエストで使用できます。

この方法で ID を表現して使用することは、REST の特徴的なアイデアであるハイパーテキスト リンクの代替手段です。

OpenAPI では、これらのパス内の変数を「パラメータ」と呼び、パスと HTTP メソッドの組み合わせをオペレーションと呼びます。これは、RPC システムと同様の用語です。

OpenAPI によるパラメーター付きの URL テンプレートの使用は、HTTP へのカスタム マッピングを使用して RPC のような概念を表現する方法とみなすことができます。

OpenAPI の長所と短所

私の意見では、OpenAPI にはその成功を説明する 2 つの基本的な特徴があります。 1 つ目は、OpenAPI モデルは、ほとんどのプログラマが慣れ親しんでいる従来の RPC モデルに似ているということです。このモデルは、使用するプログラミング言語の概念にもよく適合します。 2 番目の理由は、プログラマが RPC 概念の HTTP リクエストへのカスタム マッピングを定義できるためです。この 2 番目の特性には、利点と問題の両方が伴います。主な利点は、クライアントが標準の HTTP テクノロジーのみを使用して API にアクセスできることです。これは、クライアントが追加のテクノロジを導入する必要がなく、ほぼすべてのプログラミング言語および環境から API にアクセスできることを意味するため、パブリック API にとって特に重要です。欠点は、HTTP の詳細を設計するのに多大な労力が必要になる可能性があることです。Web 上で、何をすべきか、何をすべきではないかに関するすべてのガイダンスを確認し、その多くは矛盾していますが、消費者がそれを学ぶためにさらに努力する必要があります。

gRPC が OpenAPI よりも優れた選択肢となるのはどのような場合ですか?

OpenAPI で記述された API の設計上の課題は、「操作」とその「パラメータ」を表す URL パスと HTTP メソッドの組み合わせを定義することです。オプションがたくさんあるため、これは難しい作業になる可能性があります。ほとんどのプロジェクトにとって、それが時間とエネルギーの有効な使い方であるかどうかは明らかではありません。このアプローチから生じる不満は、前述した Pascal Chambon による SOAP と REST を比較するブログ投稿で情熱的に説明されており、冒頭の RPC 例も提供されています。

Chambon の投稿にはいくつかの誤った情報と誤解が含まれており、 彼の投稿に対する反応 はそれを修正することに焦点を当てていましたが、Chambon の間違いは、実際には RPC のような概念を HTTP にマッピングする独自の設計はかなり複雑で難しいという彼の要点を裏付けるものになっています。

Chambon のブログ投稿に応じて提供されたアドバイスのほとんどは、Chambon や他のほとんどの人がよく知っている RPC のようなモデルの代替として REST を推奨していました。これは確かにオプションです。この投稿の冒頭で説明した単純な REST の例は、それを正確に行う方法についてのミニマリストの見解です。

Chambon のもう 1 つのオプションは、基本的な RPC モデルを維持し、それを表現するために OpenAPI の代わりに gRPC を使用することです。これにより、API から HTTP へのカスタム マッピングを定義する複雑さが回避されます。 RPC モデルは、他のどのモデルよりも永続的な人気を示しており、API 設計者がとにかく RPC のようなモデルを使用する場合は、そのために利用可能なすべてのテクノロジを比較検討する必要があります。

gRPC の利点

gRPC は RPC API を次のように表現します。 インターフェース記述言語 (IDL) これは、DCE IDL、Corba IDL、その他多くの RPC IDL の長い伝統から恩恵を受けています。 gRPC の IDL は、URL パス、そのパラメータ、およびそれらとともに使用される HTTP メソッドを使用する OpenAPI のアプローチよりも、リモート プロシージャを定義する簡単かつ直接的な方法を提供します。

gRPC は内部で HTTP/2 を使用しますが、gRPC は HTTP/2 を API 設計者や API ユーザーに公開しません。 gRPC は、RPC モデルを HTTP 上にどのように階層化するかについてすべての決定をすでに行っているため、ユーザーが決定する必要はありません。これらの決定は gRPC ソフトウェアと生成されたコードに組み込まれています。これにより、API 設計者とクライアントの作業が簡素化されます。対照的に、OpenAPI では、API 設計者が特定の API の HTTP 上で RPC モデルを表現する方法の詳細を指定する必要があり、API のクライアントはその詳細を学習する必要があります。 OpenAPI アプローチの重要な利点は、API クライアントが標準の HTTP ツールとテクノロジを使用できることです。これにより、多くの API 設計者にとってその努力は正当化されます。

API で HTTP がどのように使用されるかに関係なく、プログラマーが使用できるクライアント側プログラミング ライブラリをさまざまな言語で作成することが必要になる場合があります。これらのプログラミング ライブラリは、プロシージャ (プログラミング言語によっては関数またはメソッドと呼ばれる場合があります) の形式をとります。 gRPC の最も魅力的な特性の 1 つは、プログラマーにとって直感的に使用して効率的に実行できるクライアント側プログラミング ライブラリの生成に非常に優れていることです。 OpenAPI もクライアント側のプログラミング ライブラリを生成できますが、gRPC バージョンの方がシンプルでわかりやすいと思います。これはおそらく、その IDL が RPC の概念を表現するだけでよく、これらの概念の HTTP へのマッピングを同時に記述する必要がないためです。

gRPC で指定された API は、サーバー側での実装も簡単です。 gRPC が提供するフレームワーク、ライブラリ、およびコード生成のおかげで、多くの機能があるにもかかわらず、受信リクエストを解析して適切な実装関数を呼び出す標準の HTTP リクエスト ハンドラーを作成するよりも、gRPC メソッドのサーバー実装を作成する方が簡単な場合があります。それを支援することを目的としたフレームワーク。

gRPC のもう 1 つの特徴は、優れたパフォーマンスです。 gRPC は、作成と解析が効率的なバイナリ ペイロードを使用し、HTTP/2 を活用して接続を効率的に管理します。もちろん、gRPC を使用せずにバイナリ ペイロードと HTTP/2 を直接使用することもできますが、これにはあなたとクライアントがより多くのテクノロジーを習得する必要があります。

また、gRPC は、最高の HTTP ベースの API であっても HTTP プロトコル全体を実装していないという問題も回避します。そのため、API プロバイダーとクライアントは、特定の API でサポートされている HTTP のサブセットを指定および学習する方法を理解する必要があります。これは、REST API と OpenAPI API の両方の問題です。 gRPC は、クライアントとサーバーの両方が完全な gRPC プロトコルを実装する特別なソフトウェアを採用することを要求することで、この問題を回避します。私たちは、HTTP と同様に、gRPC がそのプロトコルを少なくとも 25 年間は安定に保つことに成功し、サーバーがアップグレードされたときにクライアントが壊れたり、その逆が起こらないように願っています。

エンティティ指向モデルと RPC をどのように組み合わせますか?

gRPC と OpenAPI のどちらを使用しているかに関係なく、エンティティ指向の方法で RPC を使用するコツは、RPC メソッド定義を、標準エンティティ操作 (作成、取得、更新、および削除と呼ばれることが多い) に簡単にマップできるもののみに制限することです。クラッド³、リストに加えて) をリソース タイプごとに指定します。

エンティティ指向スタイルで RPC を使用するには、通常の RPC の思考プロセスを逆にします。プロシージャ定義から始めるのではなく、リソース タイプを定義することから始めて、それらのタイプおよび任意のタイプに対する共通のエンティティ操作に対応する RPC メソッド定義を作成します。必要と思われる追加の操作。

エンティティ指向スタイルで RPC を使用するには、制約された使用パターンを人々に教えるかどうかにかかっています。実際には、このように設計された API はエンティティ指向の概念とプロシージャ指向の概念が混在している場合があり、これにより利点の一部が損なわれることがわかります。

では、gRPC の欠点は何でしょうか?

どのテクノロジーにも欠点と制限があります。 OpenAPI のいくつかについてはすでに説明しました。

HTTP API の一般的な特徴は、クライアントがそれらを使用でき、サーバーが汎用の広く利用可能なテクノロジのみを使用してそれらを実装できることです。 API 呼び出しは、ブラウザに URL を入力するか、ターミナル ウィンドウまたは bash スクリプトで cURL コマンドを発行するだけで簡単に行うことができます。プログラマは、基本的な HTTP ライブラリ以上のテクノロジを使用して HTTP API にアクセスしたり、HTTP API を実装したりできます。対照的に、gRPC ではクライアントとサーバーの両方に特別なソフトウェアが必要です。 gRPC で生成されたコードは、クライアントとサーバーのビルド プロセスに組み込む必要があります。これは、一部の人にとっては面倒かもしれません。特に、JavaScript や Python などの動的言語での作業に慣れている人にとっては、少なくとも開発マシン上ではビルド プロセスが実行されない可能性があります。 -存在します。グーグル クラウドエンドポイント この製品を使用すると、特別なソフトウェアを使用せずに HTTP および JSON 経由で gRPC API にアクセスできるようになり、クライアントに多くのオプションが復元されますが、誰もがクラウド エンドポイントを使用したり、同等のものを見つけたり構築したりしたい、または使用できるわけではありません。

メタデータなしで REST API 全体をクロールするボットを作成するのは簡単です⁴これは、ブラウザーや Web ボットが HTML Web 全体をクロールできる方法と同様です。 gRPC または OpenAPI のどちらを使用して記述されているかに関係なく、RPC スタイルの API ではこれを行うことはできません。RPC では、各エンティティ タイプに、それを使用するためのカスタム ソフトウェアまたはメタデータを必要とする異なる API が与えられるためです。実際には、汎用 API クライアントを作成できることは、便利な場合もありますが、通常は重要ではありません。

HTTP API は、セキュリティ機能の追加、入力検証の実行、データ形式のマッピング、その他多くの問題の解決のためにプロキシされることがよくあります。これには通常、ヘッダーの追加、削除、変更、さらには本文の解析、さらには変更が必要になります。プロキシは、これを実現するために標準ヘッダーとカスタム ヘッダーを組み合わせて使用します。これらの機能は通常、従来のプログラミング スキルや gRPC を簡単に統合できる種類のソフトウェア開発環境を必要としない Apigee Edge などの製品を使用して実装されます。 gRPC でこの種のプロキシ処理を行うのははるかに難しいと思いますが、それが一般的に行われているとは知りません。