目次

APIに少しでも詳しい人なら、特にマイクロサービスとそのアプリケーションに関しては、REST APIが主に使われるAPIであることを知っているでしょう。

gRPCはHTTP/2を使用する高性能、バイナリで、強く型付けされたプロトコルですが、RESTはHTTPとJSON/XMLを使用する、よりシンプルで、テキストベースで、ステートレスなプロトコルです。gRPCはより効率的で、複雑なマイクロサービスやリアルタイムアプリケーションに適しており、RESTはより広く採用されており、基本的なAPIにはよりシンプルに使用できます。

”gRPC"の意味を理解しようとしている人も、次の開発プロジェクトでREST APIに代わるものとしてgRPCを検討している人も、このガイドを読めば理解できます。gRPCとは何か、なぜ人々はそれを使うのか、そしてgRCP APIとRESTful APIとの比較について学びます。

gRPCとRESTの主な違いは以下の通り：

  • プロトコル：gRPCはトランスポートにHTTP/2を使うが、RESTは通常HTTP/1.1を使う。
  • データ・フォーマット：gRPCはシリアライズにプロトコル・バッファを使用し、RESTは通常JSONまたはXMLを使用する。
  • API設計：gRPCはRPC（Remote Procedure Call）パラダイムに基づき、RESTはRepresentational State Transferモデルのアーキテクチャ制約に従う。
  • ストリーミング：gRPCは双方向のストリーミングをサポートするのに対し、RESTはリクエスト-レスポンスの通信パターンに限定される。

RESTはgRPCと何が違うのか？

RESTの方が人気があるのには、それなりの理由があるのでしょうか？RESTとgRPCを理解したいなら、違いに飛び込む前に知っておくべきことがいくつかあります。

API、またはアプリケーション・プログラミング・インターフェースは、アプリケーションが互いに通信し、相互作用することを可能にするルールと定義を提供します。APIは、あるアプリケーションが他のアプリケーションに対して行うことができる呼び出しやリクエストの種類、それらのリクエストの方法、使用されるデータ形式、クライアントが従わなければならない規約を定義します。

基本的にAPIは、複数の機能を接続することで、より大規模なシステムでアプリケーションを使用できるようにします。各機能は互いに動作し、相互作用することができ、さらに多くの機能やマイクロサービスを追加することができます。

マイクロサービスは、異なるプログラミング言語で書かれ、異なるプラットフォーム上で動作していたとしても、連携して動作する可能性があります。APIはその性質上、互換性があるように設計されています。APIはマイクロサービス間で必要な接続性を生み出します。

APIのアーキテクチャスタイルを理解する

REST APIとgRPC APIは、APIを構築するための異なるアーキテクチャ・スタイルを指します。両者はマイクロサービスやアプリケーションを接続するが、その方法は異なります。

各アーキテクチャ・スタイルは特定のケースで機能するように設計されているので、ニーズに基づいて決定する必要があります。

REST APIとは？

RESTは、APIを構築するための最も一般的なアーキテクチャ・スタイルです。特にウェブベースのアプリケーションやマイクロサービスベースのインフラストラクチャに有用です。

REST APIはJSONを使用します。JSONはテキストベースで人間が読めるフォーマットで、複数のプラットフォームでうまく機能します。REST APIで使用できるフォーマットはJSONだけではないが、シンプルであるため、最も一般的に使用されています。

JSONは、マイクロサービスやインターネットアプリケーション間のより良いリンクを構築し、相互通信を支援するために使用されます。これらはREST APIの最もよく使われるケースであり、いたるところで見かけることができます。RESTは、マイクロサービス間で必要に応じてメッセージを送受信するためにJSONを使用することができます。

gRPCとは？

gRPCはオープンソースのRPCアーキテクチャで、マイクロサービス間の高速通信を実現します。もともとはGoogleが通信を改善するために開発したものです。

gRPCはProtobuf（プロトコルバッファ）メッセージングフォーマットを使用します。これは構造化データをシリアライズするための高度にパックされた、非常に効率的なメッセージングフォーマットです。特定のユースケースでは、gRPC APIはREST APIよりも効率的な代替手段として機能します（これについては後で詳しく説明します）。

以下は、REST APIとgRPCの基本を比較した簡単なメトリクスを示したものです：

thumbnail image

一般的にAPIは、低速なモノリシック・アプリケーションだけに依存するのではなく、マイクロサービス・ベースのアプリケーションを作成することを可能にする。プロジェクト全体がシームレスに動くように、APIを使って複数の機能間のリンクを作る必要がある。どのAPIを使うかは、それが特殊なケースかどうかによる。

マイクロサービス、REST API、RPC APIについて

APIのトピックを理解するベストな方法の一つとして、APIを最新のマイクロサービスベースのアプリケーション開発のコンテクストで見るという方法があります。APIはマイクロサービスベースのアプリケーションを可能にするだけでなく、マイクロサービスベースのアプリケーションのコンテクストで、gRPC APIは （場合によっては） REST APIの代替になりえます。

マイクロサービスベース・アプリケーション

マイクロサービスベースのアプリケーションは、従来のモノリシック・アプリケーションの最大の制約を克服しています。モノリシックなアプリケーションは、アプリケーションのすべてのサービスと機能を管理する単一の不可分のコードベース内に、すべてのサービスと機能のプログラミングを含んでいます。

問題は、デベロッパーが既存のフレームワークの上に新しいサービスや機能を追加すると、アプリケーションの修正、アップグレード、拡張がますますしにくくなることです。 アプリの一部分を変更すると、他の部分に悪影響を及ぼす可能性があり、モノリスを何度も拡張、更新、変更すると、最終的にはコードベースが相互依存し、理解しづらくなるため、システム全体を一から設計し直さないといけなくなります。

この問題はマイクロサービスベースのアプリケーション・アーキテクチャで解決でき、このアーキテクチャスタイルでは、モノリスをそのコンポーネントサービスに分解し、各コンポーネントを自律的なアプリケーション（マイクロサービスと呼ぶ）として実行します。そして、こういった個々のマイクロサービスは、APIを使用して互いに対話やインタラクションをし、このAPIで繋がったマイクロサービスのグループが一緒になって、より大きなアプリケーション・アーキテクチャが形成されます。

異なる言語で書かれた、別々のプラットフォームで動作する自律動作のマイクロサービス同士もAPIで接続できるため、APIによってプラグイン可能なコンポーネントベースのシステムが実現できます。自律的に動作するサービスに変更を加えても、システム全体への影響が少ないため、個々のマイクロサービスのアップグレードが劇的に速く簡単になります。利用状況に応じて必要なマイクロサービスにリソースを振り分けることができるため、より簡単に効率よく拡張できるようになり、さらに、1つのマイクロサービスに障害が発生したり、速度が低下したりしても、インフラ全体がダウンする可能性は低くなります。こういったことはすべて、より効率的で強力な、且つスケーラブルで柔軟なシステムにつながるものであり、APIですべて実現可能です。

APIのアーキテクチャスタイルとして最も広く使われているのはREST APIですが、RPC APIやgRPC APIも存在します。次のセクションでは、これらのAPIが互いにどのように比較されるかを見ていきます。

REST APIを理解する

REST（Representational State Transfer）は、バックエンドのデータがJSONまたはXMLメッセージングフォーマットを通じてクライアントに提供されるクライアント・サーバー組織のことです。ロイ・フィールディング氏によると、APIは以下の制約を満たす場合に「RESTful」と認定されます：

  • 統一されたインタフェース：APIは、特定のアプリケーションリソースをAPIコンシューマに公開される
  • クライアントとサーバーの独立性：クライアントとサーバーは独立して機能し、クライアントは、アプリケーションのリソースを指すURIだけを知ることになり、通常はAPIドキュメントでそれが公開される
  • ステートレス：サーバはクライアントのリクエストに関連するデータを保存せず、クライアントはこの「ステートデータ」を（キャッシュを介して）自分の側で保存する
  • キャッシュ可能：APIによって公開されるアプリケーションリソースは、キャッシュ可能である
  • レイヤー化：アーキテクチャは階層化されており、異なるコンポーネントを別々のサーバーで管理可能である
  • COD（コード・オン・デマンド）：唯一のオプションのREST制約であり、これによってクライアントはサーバーからの応答として実行可能なコードを受け取ることができる。つまり、サーバーによって特定の物事がどのように行われるかが決定される。

最後に、REST APIのアーキテクチャは一般的にHTTPプロトコルに依存しており、REST APIはWebアプリケーションの構築やマイクロサービスの接続に最も一般的な形式です。REST APIがWebサービスとして公開されると、Webサービスが提供する各コンポーネント（またはサービス）は、リソースとしてクライアントに提示されます。クライアントは、GET、POST、DELETE、PUTといったさまざまなHTTPコマンドを受け付ける共通のインターフェースを通じて、これらのリソースにアクセスできます。

RPC APIを理解する

RESTの前身であるRPC（遠隔手続き呼び出し）は、1970年代に遡るソフトウェアアーキテクチャです。RPCでは、リモートサーバー上の関数を特定のフォーマットで呼び出し、同じフォーマットで応答を受け取ることができます。リクエストを実行するサーバーがどのようなフォーマットを使っているかは問題ではなく、それがローカルサーバーであるかリモートサーバーであるかも関係ありません。RPCを使えば、サーバー上の関数を呼び出して、同じフォーマットで結果を受け取れるのです。

RPC APIの基本コンセプトは、REST APIと似ています。RPC APIは、インタラクションのルールと、クライアントがどのようなメソッドを使用してインタラクションできるかを定義しており、クライアントは、これらのメソッドを呼び出すのに「引数」を使用した呼び出しを送信します。しかしRPC APIでは、メソッドはURLで見つかり、メソッドを呼び出すための引数は、クエリ文字列の中に含まれてます。これを説明すべく、RPC APIのリクエストとREST APIのリクエストを比較してみましょう。

  • RPC：RPC API のリクエストは POST /deleteResource で、クエリ文字列は { "id": 3 }  
  • REST：REST APIのリクエストでは、DELETE /resource/2とリクエスト

gRPC APIsについて

RPCアーキテクチャの変形として、gRPCは2015年にGoogleによって、マイクロサービスと相互作用が必要な他のシステム間のデータ伝送を高速化するために作成されました。このAPIアーキテクチャは、いくつかの理由で以前のAPIとは多少異なっています。

まず、gRPCは異なるフォーマットを使用しています。JSONを使うのではなく、APIはProtobufを使う。ProtobufもGoogleが開発したもので、言語やプラットフォームに依存しません。XMLに似ているが、より効率的だと考えられています。

このAPI構造はまた、オリジナルのHTTP1の代わりにHTTP2を使用し、オリジナルのRPCよりもかなり高速です。つまり、以前のバージョンよりも最大10倍速くメッセージを送信できるため、実装が容易になっています。大規模なアプリケーションでは、APIを実装する際にRESTよりも遅くなるものの、通信側の管理が可能になります。

最後に、gRPCは通信にSwaggerではなく独自のプライベートコード生成を使用する。これら全てについて詳しく知りたい方は、続きを読んでほしいです。

JSON/XMLの代わりにProtobufを使用

REST APIとRPC APIは、いずれもJSONまたはXMLメッセージング形式を使ってメッセージを送受信します。他の形式も使えますが、JSONとXMLが最も一般的です。このうちJSONは、柔軟性があり、効率的で、プラットフォームや言語に依存しないため、最も人気のある形式となっており、テキストベースで人間が読めるため、人間のオペレーターが作業しやすいのも特徴です。ただ、システム間でデータをやり取りする場合は、JSONでは十分な速度や軽量性が得られないという問題があります。

RESTやRPCに対して、gRPCはProtobuf（プロトコルバッファー）というメッセージングフォーマットを用いることで、メッセージ送信の速度や重さの問題を克服し、より効率よくメッセージ送信をしています。以下に、Protobufについての詳細をもう少し挙げています：

  • JSONのようにプラットフォームや言語に依存しない
  • 構造化されたデータをシリアライズ、デシリアライズしてバイナリで通信する
  • 高度に圧縮されたフォーマットであるため、JSONのような人間の読みやすさは得られない
  • JSONが管理している多くの責任を取り除き、データのシリアライズとデシリアライズにのみ集中できるようにすることで、データ転送の高速化を実現
  • Protobufでのメッセージのサイズの縮小や、軽量なメッセージングフォーマット機能による、より高速なデータ転送を実現

HTTP 1.1ではなくHTTP 2での構築

gRPCが効率性を高めるもう一つの方法は、HTTP 2プロトコルの使用です。REST APIは通常、HTTP 1.1に基づいて構築されており、リクエスト・レスポンス型の通信モデルを採用しています。つまり、マイクロサービスが複数のクライアントから複数のリクエストを受けると、一回につき1つずつ処理しなければならず、システム全体が遅くなるということになります。REST APIもHTTP 2を使えますが、依然としてリクエスト・レスポンス型に限定されており、HTTP 2がサポートする双方向のストリーミング通信の利用はできません。

これに対し、gRPCはHTTP 2を使用しており、HTTP 2がサポートするクライアント・レスポンス通信と双方向通信の両方を利用します。そのため、gRPC はHTTP 1.1と同様のクライアントが1つのリクエストを送信し、サーバーが1つのレスポンスを送信するというような「単項」なやり取りの管理ができます。同時に、クライアントは、各RPCコールが新しいHTTP 2ストリームを開く長寿命接続を開くこともでき、これは「双方向」、「多重の」、または「ストリーミング通信」としても知られています。

HTTP 2 では、マイクロサービスが複数のクライアントから複数のリクエストを受け取った場合、多くのリクエストとレスポンスを同時に提供することで多重化を実現します。この点で、gRPC APIはREST APIの制限から外れ、常に情報を流し続けます。

gRPCが利用できるストリーミングは3種類：

  • サーバー側：クライアントがサーバーにリクエストメッセージを送信し、サーバーはレスポンスの一連をクライアントに返す。応答が完了すると、サーバーはステータスメッセージ（場合によっては末尾のメタデータも）を送信し、処理が完了。すべての応答を受信した後、クライアントは処理が完了する
  • クライアント側：クライアントはサーバーに一連のリクエストメッセージを送信し、サーバーはクライアントに一つの応答を送る。サーバーは（通常）クライアントからのリクエストとステータスメッセージ（場合によってはメタデータの末尾）をすべて受け取った後にレスポンスを送信する
  • 双方向：クライアントとサーバーが、特別な順序を踏まずに互いにデータを転送する。この種の双方向ストリーミングはクライアントから開始され、接続終了もクライアント側による。

サードパーティツールを使わず、生来のコード生成を実現

コード生成機能は、gRPCに内蔵されたprotocコンパイラによるネイティブ機能です。REST APIでは、Swaggerのようなサードパーティツールを使って、様々な言語でのAPI呼び出しのコードを自動生成しなければいけません。gRPCに付属するprotocコンパイラは、さまざまなプログラミング言語と互換性を持っているため、gRPCはポリグロット環境（異なる言語でコーディングされ、別々のプラットフォームで動作する様々なマイクロサービスを多数接続する環境）に最適です。

これに対し、REST APIはネイティブのコード生成機能を備えておらず、異なる言語でのAPIコールのコードを生成するには、Swaggerのようなサードパーティツールの使用が必要です。これは不便というわけではありませんが、gRPCがコード生成のために外部ツールに依存しない点は注目すべきです。

7～10倍の速さのメッセージ送信

ルワン・フェルナンド 氏が発表したテストによると、gRPC API接続は REST API接続よりも驚くほどずっと速く、実際7倍から10倍の速さであると報告されています。「gRPCは、この特定のペイロードのデータ受信はRESTのおよそ7倍、データ送信はRESTのおよそ10倍高速です。これは主に、プロトコルバッファのタイトパッキングと、gRPCによるHTTP/2の使用によるものです。」

RESTよりも遅い実装

gRPC APIの実装は、メッセージの転送速度にメリットがあるにもかかわらず、REST APIの実装に比べて非常に時間がかかります。ルアン・フェルナンド氏によると、単純なgRPC Serviceの実装には約45分かかるそうです。WebやREST APIの実装には、10分程度しかかかりません。

フェルナンド氏の報告によると、この追加実装時間は、サードパーティのツールにgRPCのサポートが組み込まれていないことを反映しているとのことです。これは、特にREST APIが広く普及しているのに比べて、gRPCがまだ広く採用されていないことが主な理由だそうです。以下は、フェルナンド氏がgRPCの実装時間について語ったものです。

「このシンプルなgRPCサービスの実装にはおよそ45分かかりましたが、WebAPIの構築には10分ほどしかかかりませんでした。これは主に、RESTがずいぶん前に主流になり、ASP.NET Core MVCなどのほとんどの主要なフレームワークが、（規約やパターンによって）そのようなサービスを素早くスピンアップするためのサポートを内蔵しているためです。」

どのような場合にRESTとgRPCを使い分けるべきか？

つの選択肢がある中で、どちらのAPIを使うべきか？それは本当に、あなたが取り組んでいるプロジェクトと、APIに何をさせる必要があるかによります。RESTは今でも最も一般的だが、だからといって自動的に使われるべきというわけではないです。

REST API使用のタイミング

REST APIは、マイクロサービスベースのインフラ接続のための最も広く使われた、一般的なAPIです。社内システム構築でも、リソースを外部に公開するオープンシステム構築でも、アプリ統合の事実上の選択は、非常に長いことREST APIであり続けるでしょう。また、HTTPプロトコルの高速な反復と標準化が必要なシステムには、REST APIが最適です。

サードパーティツールからの普遍的なサポートがあれば、アプリの統合、マイクロサービスの統合、Webサービスの開発において、最初に検討すべきはREST APIです。

gRPC API使用のタイミング

gRPC に関しては、ほとんどのサードパーティツールがgRPC互換のための機能を内蔵していないのが現状なため、gRPCは内部システム、すなわち外部ユーザー向けでないインフラの構築に利用されるのがほとんどです。ただし、以下のような場合には、gRPCのAPIは有用であると考えられます。

  • マイクロサービス接続：gRPCの低遅延かつ高速なスループット通信は、メッセージ伝送の効率が最も重要な軽量マイクロサービスからなるアーキテクチャの接続に特に有用である
  • 多言語システム：gRPCは、幅広い開発言語のネイティブコード生成サポートで、ポリグロット環境での接続管理において優秀である
  • リアルタイムのストリーミング：リアルタイム通信が必要な場合、gRPCの双方向ストリーミング管理機能により、システムは単項のクライアント・レスポンス通信を待つことなく、リアルタイムでメッセージの送受信が可能
  • 低電力低帯域ネットワーク：特にJSONと比較した場合、gRPCの同列化されたProtobufメッセージの使用は、帯域幅が制限された低電力ネットワークに軽量メッセージ、より高い効率、および速度をもたらし、IoTは、gRPC APIの恩恵を受けることができるこの種のネットワークの一例である

APIを文書化する方法

REST APIであれgRPCであれ、ドキュメンテーションは不可欠です。RESTの方が人気があるとはいえ、指示と情報が必要です。クライアントはその使い方を理解し、自分のアプリケーションに追加するすべてを設定できなければなりません。この優れた例が、WordPressに機能を追加する場合です。追加のマイクロサービスは、注文の追跡から多言語翻訳の提供まで、あらゆる機能を提供することができます。あなたのドキュメンテーションは、どのようなクライアントでも使用でき、APIを素早くセットアップできるように十分に明確であるべきです。

何を含めるべきか？以下の点は、ユーザーが知っておくべき必須事項です：

  • APIに関連するエンドポイントは何か？
  • どのような用語が使われ、どのように定義されているか。
  • エンドポイントへのリクエスト例を提供すること。
  • 様々なプログラミング言語の統合方法に関する情報。
  • 簡単な参照とトラブルシューティングのために、様々なエラーメッセージとステータスコードを共有すること。
  • たとえ簡略化されすぎているように見えても、ステップ・バイ・ステップで進めましょう。

APIの使い方やプログラムへの追加方法についてのチュートリアルが含まれている必要があります。多くの人は手順をビデオで見ることを好むが、簡単に参照できるように書き出すこともできます。APIドキュメンテーションは、そのシステムを本当によく知っていて、わかりやすくシンプルに書ける人が作るべきです。

多くの場合、ドキュメントは辛口で技術的なものになりがちなので、誰もが使えるようにするために何度も確認する必要があるかもしれません。そのためには、必要に応じて素人用語を使う必要があるかもしれません。また、クライアントがフォローしやすいように、ステップに番号を振ることも検討すべきです。

APIをゼロから自分でコーディングして作成する場合、ドキュメントの作成はより複雑になることが多いです。あなたは物事の技術的な側面に完全に包まれることになり、クライアントに説明するのは難しいかもしれません。その代わりに、エンドユーザーと彼らが知る必要があることに焦点を当てようです。エンドユーザーは、必ずしも物事の仕組みを知る必要はないです。

外部のプラットフォームを使ってAPIを作成すれば、それに付随するドキュメントの作成がより早く簡単になることがわかるでしょう。

APIをより速く構築する方法

REST API開発は、最新のマイクロサービスベースのアプリケーションアーキテクチャを開発するために不可欠です。しかし、単純なREST APIを手作業でコーディングする場合、数週間かかることがあります。これだけ時間がかかるのだから、代替案を検討したくなるでしょう。例えば、DreamFactory IPaaSやAPI Gatewayのようなプラットフォームが役立ちます。

DreamFactoryプラットフォームの最も便利な機能の1つは、REST APIを自動的に生成する能力である。DreamFactoryを使用すると、事実上あらゆるデータベースやサービスに接続するための、完全にSwaggerで文書化されたREST APIを数分で生成できます。

これらのプラットフォームは、APIをよりシンプルかつ迅速に作成できるように設計されています。コーディングは不要で、コードを1行も学ぶことなく必要なすべてを行うことができます。

RESTとgRPCの比較についてのまとめ

gRPCを未来のAPIと考える人もいます。しかし、その方向に確実に傾くにはまだ時間がかかるでしょう。お分かりのように、現時点ではgRPCはあまり人気のあるAPIではないし、近い将来開発者が広く使い始めるかどうかも疑わしいです。

RESTは普遍的にサポートされており、マイクロサービスが存在するあらゆる場所で既に使用されています。あなたのユースケースがgRPCの実装を要求しない限り、この黎明期（広く普及する前）にリスクを冒してgRPCを採用することは現実的ではないし、必要でもないです。

現時点では、そしておそらく予測可能な将来においても、REST APIが最良の選択肢です。

Integrate.io API Managementサービス：マイクロサービス間をつなげるREST APIを数分で自動生成!

REST APIの開発は、最新のマイクロサービスベースのアプリケーションアーキテクチャ開発に不可欠な要素ですが、単純なREST APIを手作業でコーディングすると数週間かかることがあり、プロジェクトにとって大きな人件費と遅延が発生します。そこで、Integrate.io API Managementサービス （iPaaSとAPIゲートウェイ）がお役に立ちます。Integrate.io API Managementサービスの最も有用な機能の1つとして、REST APIの自動生成があります。Integrate.io API Managementサービスで、事実上あらゆるデータベースやサービスに接続するための、完全にSwaggerで文書化されたREST APIを数分で生成できます。

データ統合プラットフォームであるIntegrate.io内では、企業はクラウド上でデータの統合、処理、分析のための準備を行うことができます。コードや専門用語を有しなくても使用できる環境であるため、ハードウェア、ソフトウェア、または関連インフラに投資することなく、どのような組織・個人でもビッグデータがもたらす機会をご享受頂けます。

14日間無料トライアル、無料デモやご相談はこちらのリンクよりリクエストをお願い致します。後ほど、弊社担当者よりご連絡させて頂きます。