ソフトウェア開発に関して、REST のような言葉が飛び交うのを聞いたことがあるかもしれません。REST は非常によく使われるAPIアーキテクチャで、開発者はソフトウェア API を設計するために広くこのアーキテクチャを使用しています。アプリケーションプログラミングインターフェースは、どんなソフトウェアアプリケーションにとっても不可欠であり、REST は、APIに使用される多くのアーキテクチャの1つである。
現在では gRPCアーキテクチャは人気を博しており、従来REST APIに付随していたいくつかの問題を解決するとも言われています。しかし、両者はどこが違うのでしょうか？そして、あなたのアプリケーションにはどれを使うべきなのでしょうか？これらの質問に対する答えを知るためには、以下のことをもっと理解する必要があります。 gRPCとREST の違いや、どのような場面でどちらが優れているのかを理解する必要があります。しかし、そのすべてに入る前に、APIとは何か、そしてAPIがマイクロサービスに対して何をもたらすかを見てみましょう。
APIとは？
ソフトウェアアプリケーションは、技術的な仲介役として動作するアプリケーションプログラミングインターフェース（API）を使用することで、相互に作用し、通信することができます。APIは、ユーザーのリクエストをシステムに送信し、システムから返信を受け取る役割を担っている。
例えば、オンラインで携帯電話を注文する場合を考えてみましょう。Webと連携しているサイトにアクセスすると、問い合わせの情報がサーバーに送信されます。サーバーはその情報を取得し、分析し、必要な処理を行った後、画面に表示される内容を返信する。これを可能にするのがAPIである。
APIは、そのようなクライアントのリクエストをどのように実行するか、どのようなデータ構造を使用するか、クライアントが遵守すべき標準を概説します。また、あるプログラムが別のプログラムに送ることのできるクエリの種類も記述されている。どちらも gRPCvsREST アーキテクチャーのスタイルは、APIの設計に広く使用されています。
APIとマイクロサービス
アプリケーションには、モノリシック・アーキテクチャとマイクロサービス・アーキテクチャがある。モノリシック・アプリケーションでは、ソフトウェアのすべての機能やモジュールが1つのユニットまたはコードベースに収められている。これに対し、マイクロサービス・アプリケーションは、HTTPプロトコルのようなインターフェイスを介して相互に作用する多数の小さなユニットで構成されている。
モノリシックスタイルの主な問題点は、エンジニアが既存の基盤の上に新しい機能やサービスを追加していくため、システムの変更、更新、拡張が困難になることです。アプリケーションのある部分を変更すると、他の部分に悪影響が及ぶ可能性があります。モノリスのコードは、何度も拡張、更新、変更されるうちに、次第に絡み合って理解するのが難しくなり、システムの完全な再設計が必要になるのです。
この問題は、マイクロサービスによって解決されます。このアーキテクチャ設計では、モノリスを構成要素に分割し、その各コンポーネントを個別のアプリケーションとして動作させます。これらのアプリケーションのそれぞれは、マイクロサービスと呼ばれます。そして、これらの個別のマイクロサービスは、APIを使って接続されます。このAPIで結ばれたマイクロサービスの集合体が、より大きなアーキテクチャデザインを構築することになる。APIは、マイクロサービス・アーキテクチャに組み込まれた各コンポーネント間の接続と通信を可能にする。APIを作成するための一般的なアプローチとして、GraphQL, RPCおよびREST 。
は何ですか？ RPC?
とは？ RPC- リモートプロシージャコール - は、あらかじめ定義されたフォームを使用してリモートサーバー上のサービスを実行し、同じ形式の応答を取得することができますWebアーキテクチャです。問い合わせを行うサーバーのスタイルは、ローカルサーバーかリモートサーバーかは、設計上考慮されません。 RPC設計されています。
画像出典 itrelease.com/Author Junaid Rehman
APIリクエストの基本的な機能は RPCAPIリクエストの基本的な機能は、REST APIと同じである。は、以下の通りである。 RPCAPIリクエストは、相互作用のガイドラインと相互作用を可能にするテクニックを指定する。その後、ユーザーはパラメータを使ってこれらの機能を呼び出す。URLのリクエスト文字列には、操作の呼び出しに使用するパラメータが含まれる。
APIリクエストを作成するために、システムは RPC システムは、クライアント・サーバー構造を採用している。 RPCは、ユーザーが要求した情報を解釈し、サーバーに送信する。サーバーの内部通信は秘匿され、サーバーはユーザーに応答する。この RPCまた、ユーザが特定の方法でサービスを要求することも可能である。 RPCは、分散型とオンプレミスの両方のシナリオでリモートプロシージャコールをサポートするという利点があります。
REST とは？
REST - Representational State Transfer -JSON またはXML通信を介してユーザーがバックエンドの情報にアクセスするクライアント・サーバーアーキテクチャを指します。以下のような場合、APIはRESTfulとみなされます。
- 一貫したインターフェースを持ち、APIクライアントに特定のアプリリソースを提供する。
- サーバーとクライアントは別々に独立して動作する。アプリケーションのコンポーネントを指すURIのみがクライアントに知らされる。
- ステートレスである。つまり、クライアントだけがあらゆる状態情報を保存する。サーバーは、クライアントのクエリに関する状態データを一切保存しない。
- APIによって提供されるアプリケーション資産は、キャッシュ可能でなければならない。
- レイヤードアーキテクチャを採用している。
ハイパーメディアネットワークでのデータ伝送を可能にするために、いくつかの制限に依存する現代のアーキテクチャ設計の応用である。RESTful Web APIは、HTTPプロトコルを使用してサービスに接続するために、URLエンコードされた引数を必要とする。 REST APIは、ステートレス、拡張性、信頼性の高いAPIを作成するために、現代のWebデザインに広く受け入れられています。
マイクロサービスシステムを結合する各コンポーネントは、REST APIが一般にアクセス可能になると、資産としてユーザーや顧客に表示されるようになります。このリソースは、HTTPGET,POST,PUT,DELETE のコマンドで問い合わせることができます。
REST の仕組みは？
REST は、APIリクエストで指定されたサービスを操作する際のデフォルトの通信プロトコルとして、HTTPプロトコルを使用します。リソースとは、オブジェクト指向設計におけるオブジェクトに相当するものである。RESTfulなリソースは、オブジェクトと同じように、アクションと属性を持ちます。一般に、 の実装では、RESTful アクションについてはあまり考慮されず、代わりにリソースの属性に集中するのが普通です。RESTfulなソリューションとは、RESTfulなリソースを表現するために属性を使用するだけのソリューションです。REST
RESTful API では、ユーザーが URL（Uniform Resource Locator）にクエリを送信すると、JSON 、XML、またはサポートされている任意のデータ形式でペイロードを含む応答が返されます。このペイロードは、ユーザーが必要とするリソースを表します。一般的なクライアントリクエストは以下の通りです。
- リソース上で処理される内容を指定する HTTP メソッド
- リソースのパス
- クエリに関するデータを持つヘッダ
- クライアント固有のメッセージペイロード
ヘッダーの Accept フィールドで、ユーザが受信可能なデータ型を指定する。レスポンスボディに採用されているメッセージ配信形式を特定する content-type ヘッダは、API サーバーが問い合わせを行ったユーザーに配信するデータペイロードとともに送信されます。また、APIコールの結果ステータスをユーザーに通知する応答コードも、レスポンスボディに含まれる。
とは何 gRPC?
gRPC- Google Remote Procedure Call - は、RPC デザインのサブタイプです。 gRPCは、マイクロサービスアーキテクチャのための柔軟性と速度を保証する高性能なグローバル、オープンソースのRPC アーキテクチャです。関数呼び出しは gRPCは、さまざまなコーディング言語を使用して作成されたマイクロサービスにおいて、顧客とのインタラクションを確保するために使用されます。
この手法は、HTTP 2.0規格を使ったRPC APIリクエストを実装しているが、サーバーもAPIプログラマーもHTTPを意識することはない。その結果、RPC の原則をどのようにHTTPに変換するかを気にする必要がないため、煩雑さが軽減される。
Google Remote Procedure Callは、マイクロサービス間のデータ転送を高速化することを目的としています。リモートリターンやリモートコールを可能にするために、サービスを特定し、方法論を確立し、適切な変数を指定する戦略に基づいている。
さらに、IDL - Interface description language - を使用して、RPC APIパラダイムを指定し、リモート機能の特定をよりシンプルにします。IDL では、サービスインタフェースとペイロードメッセージの形式を定義するために、デフォルトで Protocol Buffers を採用しています。
どのように gRPCはどのように機能するのでしょうか？
HTTP/2プロトコル、ストリーミング、およびプロトコルバッファ（protobufs ）は、メッセージの伝送に使用されます。 gRPCAPIはメッセージを伝送するために使用されます。protobufと呼ばれるシリアライゼーション標準は、ユーザーライブラリの自動作成とマイクロサービスのわかりやすい構築を可能にします。API設計者はプロトファイルで、サーバーとクライアントの間で送信される操作とメッセージを記述します。
protoc コンパイラはファイルをロードし，リモートサービスと通信するためのユーザソフトウェアとサーバソフトウェアを作成します．XMLやJSON のフォーマットに比べて、プロトコルバッファで暗号化されたメッセージはかなり小さいので、CPU の処理負荷が軽減されます。
さらに、HTTP/2を使用します。 gRPCAPIは、RPC の設計にさまざまな改善をもたらします。このプロトコルは、パケットをより小さなバイナリフレームのメッセージに分割するバイナリフォーマットレイヤーを追加し、トランスポート可能で小さなメッセージにレンダリングします。1つのチャンネル内で多くのコールを実行することは、HTTP/2の双方向通信アーキテクチャによる複数同時クエリのサポートによって可能になります。
HTTP/2 トランスポートプロトコルは、複数の同時ストリームをサポートしますが gRPCAPIはチャネルを介してこの機能を拡張します。各チャンネルは、多くの同時接続を介して同時に実行される複数のストリームを収容することができます。チャネルは、指定されたアドレスとポートでAPIサーバーに接続するための簡単な方法を提供します。また、クライアントスタブもチャネル経由で作成することができます。
gRPCvsREST: 比較
Google は gRPCは、既存の API アーキテクチャスタイルの制限に対処するため、RPC の亜種として作成されました。REST APIに付随するいくつかの問題を解決しているが gRPCより新しい技術であるため、APIは特定の問題に直面している。REST APIがあなたのアプリケーションにより適していると思われるユースケースはたくさんあります。2つのAPIの違いを知れば、どちらのAPIがあなたのソフトウェアに適しているか判断することができます。
HTTP 1.1 と HTTP 2 の比較
REST APIで使用されているリクエスト・リプライ方式は、主にHTTP 1.1に基づいています。これは、マイクロサービスが複数のクライアントから多くのクエリを受け取った場合、モデルがすべてのクエリを個別に処理しなければならないことを意味し、システム全体の足を引っ張ります。 REST APIはHTTP 2で開発することもできますが、通信アーキテクチャがリクエスト・レスポンスのままなので、双方向の互換性やストリーミングインタラクションなど、HTTP 2の利点を十分に生かすことができません。
gRPCAPIはこのような課題に遭遇することはありません。これは、クライアント・レスポンス型の接続モデルを採用し、HTTP 2.0をベースにしています。 gRPCは、様々なクライアントから多くのクエリーを受け付け、ストリーミング情報によってそれらのリクエストを同時に処理することができる。このような事情から、ストリーミングによる双方向通信が可能である。さらに gRPCは、HTTP 1.1 で作られたような単項のインタラクションをサポートします。
gRPC APIの管理は可能です。
- 単項のインタラクション
クライアントが1つのリクエストを行い、そのお返しにたった1つの返答が与えられる場合。 - サーバーストリーミング
サーバーがクライアントのクエリにメッセージのストリームで答えることをサーバーストリーミングという。サーバーは、すべてのデータを提供した後、処理を終了するためにステータスメッセージも送信する。 - クライアントストリーミング
クライアントが一連のメッセージを送信し、サーバーが1つのメッセージで応答する場合です。 - 双方向ストリーミング
サーバーとクライアントのチャンネルが独立しているため、双方向のデータ通信が可能です。
ブラウザ対応
ほとんどのWeb APIインタラクションはオンラインで行われるため、ブラウザのサポートは gRPCvs.REST 。ブラウザのサポートは、REST のAPIと比較した場合の重要な利点のひとつです。 gRPC.すべてのブラウザは、REST API のフル機能とブラウザサポートを提供します。しかし gRPCの機能はまだ比較的制限されています。残念ながら、HTTP 1.1 と HTTP 2 の間の移行は、 プロキシ層だけでなく gRPC-web を必要とします。その結果 gRPC例えば、特定の組織のバックエンド情報や機能を利用するAPIアプリケーションなど、内部システムやプライベートなシステムで利用されることが多くなっています。
HTTP/2プロトコルでは、多重化されたストリームが使用されます。その結果、多数の顧客がそれぞれ新しいTCPセッションを開く必要なく、並行してクエリーを送信することができます。さらに、サーバーは既存のリンクを使用して、クライアントにメッセージを配信することができます。
表現型状態遷移モデルは、HTTP 1.1を統合しているため、広くブラウザのサポートを受けています。REST が実現する HTTP 1.1 は、問い合わせのたびに TCP ハンドシェイク方式を使用します。 REST ハンドシェイクに時間がかかるため、APIはしばしば遅延の問題を抱える。
ペイロードのデータ構造
を見ながらペイロードのデータ構造を見ていると、以下のようなことがわかります。 gRPCvsREST, gRPCAPIは設計上、Protocol Bufferを使ってペイロードデータをシリアライズする。この方法は、メッセージをより小さくし、高度に圧縮された構造を可能にするため、より軽量です。プロトコルバッファはバイナリ形式であるため、データ交換のために、情報をシリアライズ、デシリアライズします。Protobufは、大きく書かれたメッセージをクライアントとサーバのプログラミング言語に自動的に翻訳することができます。
RESTペイロードのデータ構造としては、JSONが一般的だが、情報の受け渡しには、JSON やXML形式が用いられることが多い。JSON は、正確な構造を必要としないが、動的なデータの通信に適しており、最も広く用いられている形式である。また、ProtobufにはないJSONの可読性の高さも重要な利点の一つです。
JSON しかし、JSONは、データ転送を伴うと、それほど高速でも軽量でもありません。これは、 を使用する場合、サーバ側とクライアント側の両方で採用されているプログラミング言語にシリアライズして翻訳する必要があるためです。 。これは、データ転送の過程で追加のステップとなり、効率を損ねたり、ミスの可能性を高めたりする可能性があります。JSON REST
コード生成
APIクエリのコード生成には、Postmanのようなサードパーティツールを使用する必要があります。 gRPCとは異なり、REST APIにはコード生成機能が組み込まれていない。これとは対照的に gRPCは、多くのプログラミング言語をサポートするprotoc コンパイラーを備えているため、ネイティブのコード生成機能を提供します。特に、複数のプラットフォームや言語で作成された多数のサービスを組み合わせるマイクロサービスでは、コード生成は有利に働く。全体として、コード生成が組み込まれていることで、ソフトウェア開発キット（SDK）の構築が容易になります。
REST 一方、APIはネイティブなコード生成機能を備えていない。複数の言語でのAPI呼び出しのためのコード生成を行うには、サードパーティーのプログラムを利用する必要がある。手間はかかりませんが、注意しなければならないのは gRPCはコード生成のために他のサービスに依存しないことです。
REST APIを使用する場合
比較する場合 gRPCvsREST, マイクロサービス上に構築されたインフラストラクチャを統合するために最も広く採用され、好まれているAPIはREST APIです。 REST APIは、内部ネットワークを構築する場合でも、資産を世界に開放するオープンプラットフォームを構築する場合でも、アプリ接続のためのデフォルトオプションとして、非常に長い間、採用され続ける可能性があります。 REST また、APIは、迅速なイテレーションとHTTPプロトコルの標準化を必要とするシステムにも最適です。
REST APIは、サードパーティーの技術が普遍的にサポートしているため、Webサービス開発、マイクロサービス、アプリのインターフェイスの最初の選択肢となりえます。とは異なり gRPCとは異なり、幅広いブラウザをサポートし、プライベートなシステムに限定されることはありません。このため、REST APIは多くの文脈で非常に有用となりえます。
また、REST 、インターネット上で利用可能なAPIドキュメントが充実しているため、学習が容易です。このように学習が簡単なことは、時間に追われている場合には非常に重要です。調査や学習の時間を大幅に短縮し、すぐに実装を開始することができます。RESTful APIは、アプリケーションに統合するのも簡単です。RESTful APIは、拡張性にも優れています。アプリケーションをすぐに拡張したい場合は、REST APIを使用する方がよいかもしれません。状態や機密性がないため、特定のアプリケーションでは、表現的状態遷移の問題が発生する可能性があります。アプリケーションに支払いオプションがある場合 gRPCの方がよいかもしれません。
いつ使うか gRPCAPI
両者において gRPC対REST では、サードパーティツールの大半は、まだコンプライアンスに対応した機能を内蔵していません。 gRPCのコンプライアンスに対応する機能を内蔵していない。その結果 gRPCAPIは、外部のユーザーがアクセスできないような内部システムや仕組みを作るために使われることがほとんどです。この資格を念頭に置くと、次のような状況で利用することができる。 gRPCAPIを利用する。
- マイクロサービス接続
gRPC特に、低レイテンシーで高速な通信が可能なため、メッセージ配信の有効性が重要な軽微なマイクロサービスからなるアーキテクチャの連携には、APIが有効である。
- 多言語システム
gRPCgRPCは、幅広いプログラミング言語に対するネイティブコード生成機能により、ポリグロットコンテキストでの通信処理に優れています。
- リアルタイムストリーミング
リアルタイム通信が必要な場合、gRPCの双方向ストリーミング機能により、Unaryクライアントとレスポンスのやりとりを待つことなく、リアルタイムでデータを送受信することが可能です。
- 低消費電力、低帯域幅のネットワーク
このようなネットワークでは、gRPC のシリアライズされた Protobuf セッションの使用により、軽量な通信、効率性の向上、および迅速性がもたらされるため、その恩恵を受けることができます。例えば、このAPIの恩恵を受けるネットワークは、モノのインターネットです。 gRPC例えば、モノのインターネット（Internet of Things）です。
AppMaster はどのように役立つのでしょうか？
プログラミングはここ数十年で大きく変化し、新しい技術やフレームワークが開発者の作業を容易にしています。No-code 世代はこれを次のレベルへ押し上げます。のようなプラットフォームがあれば、急な学習曲線に悩まされることなく、より迅速にアプリケーションを開発することができます。 no-codeAppMasterのようなプラットフォームで、より迅速にアプリケーションを開発することができます。
AppMaster gRPC は、アプリケーションの特定のニーズに合わせてソースコードを一から作成するのに役立ちます。生成されたコードはあなたのものであり、あなたのニーズに従って修正することができます。アプリケーションに必要な様々なモジュールを で作成することができます。これは、開発チーム全体に同じことをさせるよりも、はるかに費用と時間がかかりません。AppMaster
開発者は、バックエンドのマイクロサービス・アーキテクチャ間で gRPC開発者は、AppMaster のno-code 生成プラットフォームを使って、バックエンドのマイクロサービス・アーキテクチャ間で、プロトコルを使ってクエリーを送信できます。私たちは、APIを gRPCを追加する予定です。 gRPC翌年にはモバイルアプリにもAPIを追加し、サポート体制を強化する予定です。 gRPCサポートします。
まとめ
これまでAPI開発といえば、Representational State Transferが主流でした。しかし、その間に gRPC対REST, gRPCAPIは徐々に普及しつつあります。様々な特徴が際立つものの、ブラウザのサポートやAPIドキュメントの不足といった問題もあり、どこでも採用するのは難しい。しかし、技術の進歩とコミュニティの成長により、今日の課題を克服することが期待できます。 gRPCが今日の課題を克服してくれることを期待したい。
最後に、REST か gRPCあるいはGraphQL やSOAP のような他の API メソドロジーのどれを選ぶかは、プロジェクトの特定のニーズに依存します。の利点を必要とするアプリケーションもあれば、基本的な gRPCが提供する利点を必要とするアプリケーションもあれば、REST が提供する基本的な機能を必要とするアプリケーションもあるでしょう。この2つの技術のどちらを選ぶかは、アプリケーションの機能とユースケースを評価する必要があります。
