近年、APIの設計手法としてGraphQLやgRPCが使われるようになってきました。
慣れ親しんだRESTを使った方が良いのか、新しい設計手法を試した方が良いのか、迷う方も多いのではないでしょうか?
この記事では、それぞれのAPI設計の特徴や、プロダクトごとに選択するべき設計手法・ユースケースについてご紹介します。
新規プロダクト開発にどの手法を用いれば良いかお困りの方は、参考にして頂ければと思います。
最初に、RESTからご紹介します。
Representational State Transfer(REST) は、アプリケーション開発で最も一般的なAPI設計です。
URLを使用してリソースを指定し、HTTPメソッドを使用して実行するアクションを決定します。
HTTPメソッドには以下のような種類があります。
GET | 既存のリソースを取得する |
POST | 新しいリソースを作成する |
PUT | リソースが存在する場合はリソース全体を更新し、存在しない場合は作成する |
DELETE | リソースを削除する |
PATCH | 既存のリソースを部分的に更新する |
また、RESTはステートレスという特徴を持っています。
クライアントのリクエストには、サーバーがリクエストを処理するために必要なすべての情報が含まれており、サーバーはクライアントの状態を保持しません。
HTTP標準のメソッドを使用してCRUD操作を実装できます。
また、アーキテクチャを簡素化および分離する統一されたインターフェースがあります。
多数のコンポーネントとそれらの間の相互作用のサポートを可能にします。
複数のアプリケーションを簡単に統合することも可能です。
オーバーフェッチやアンダーフェッチなどで、必要のないリソースを取得することがあります。
そのため、ペイロードが大きくなりがちです。
では、RESTはどんなプロダクトに向いているのでしょうか。
RESTは昔からあるAPIの設計手法で、さまざまなプロダクトに用いられています。
そのため、どんなプロダクトでも平均的に使いこなすことが可能です。
GraphQLやgRPCを使うメリットが特になければ、比較的どんなプロダクトにも使えるRESTを利用すれば良いでしょう。
開発に不慣れな場合にも、学習コストの低さや情報量の多さもメリットとなり得ます。
また、多くのリクエストと限られた帯域幅を処理する場合にも、RESTがお勧めです。
このような場合は、キャッシュサポートを使用してパフォーマンスを向上させることができます。
まとめると、RESTは下記のケースに適しています。
次は、GraphQLについてご紹介します。
GraphQLは、2015年に導入されたデータクエリ言語です。
これにより、開発者は必要なデータを必要な分だけ取得できます。
RESTと比較すると、GraphQLはクライアント主導のアプローチであり、必要なデータやデータの取得方法、および形式をクライアントが決定できます。
また、クライアントが必要なデータを特定できるため、RESTのデメリットであるオーバーフェッチとアンダーフェッチの問題も解決されます。
GraphQLは、主にクエリとミューテーション、サブスクリプションを使用してデータを操作します。
クエリ | サーバーからデータを要求すること |
ミューテーション | サーバー側のデータを変更すること |
サブスクリプション | リアルタイムでのデータ処理 |
GraphQLを取り入れたプロダクトとして有名なのがGithubです。
GitHubは、2016年にRESTからGraphQLに切り替えています。
Githubのように数千万人規模のユーザーを抱え、データ取得の数が多くなるようなプロダクトには必要なデータだけ取り出せるGraphQLが適していました。
RESTのデメリットであるオーバーフェッチやアンダーフェッチが発生しません。
クライアントが要求するものを過剰に取得することなく正確に提供します。
クライアントは、必要なデータ、必要な方法、および取得する形式を決定します。
クライアントが柔軟にデータを取得できる一方で、サーバー側で面倒な処理をおこなう必要があります。
そのため、サーバー側の開発の負担が増します。
またサーバー側で複雑な処理をするようになると、パフォーマンスの予測も困難になることがあります。
標準でキャッシュがサポートされていません。
RESTとgRPCに比べて、学習コストが高いです。
GraphQLでの開発に慣れていないと、うまく運用できない可能性があります。
では、GraphQLはどのようなプロダクトに適しているのでしょうか。
GraphQLはオーバーフェッチを排除し、特定の形式で必要なデータのみを取得して、アプリケーションのパフォーマンスを向上させることができます。
そのため、データ量を管理することが重要になるスマートフォンなどのプラットフォームに適しています。
GraphQLを使用して、これらのデバイスでホストされているアプリケーションが必要とする正確なデータを返すようにすると、帯域幅の消費が削減されます。
アプリケーションがモバイルで利用されることが想定される場合は、GraphQLの利用を考えてみても良いでしょう。
また、GraphQL は複数のデータソースから応答を構築できます。
すべてのデータを 1 つの応答にネストできるため、レポートダッシュボードなどのアプリケーションにも適しています。
さらに、クライアントがAPIをどのように利用するかを完全に理解していない場合にも、GraphQLを使用できます。
GraphQLでは、事前に厳密なAPIを定義する必要はありません。
クライアントが必要とするデータが明らかになっていくにつれてAPIを徐々に構築できます。
そのため、アプリを構築しながら柔軟にデータのやりとり内容を決めていく場合にも相性が良いです。
まとめると、GraphQLは下記のケースに適しています。
最後に、gRPCについてご紹介します。
gRPCは、Googleが開発したRPCフレームワークです。
OSSとして提供されており、言語が異なるサービス間の通信や、さまざまなプラットフォームで利用することができます。
データのシリアル化にプロトコルバッファ(Protobufs) を使用することで、非常に軽量で高速なAPIを提供します。
非常に軽量であるため、gRPC はクライアントの計算能力が限られている場合によく使われます。
gRPC は、コンパクトなデータフォーマット、トランスポート層としてのHTTP/2の使用、およびメッセージの高速なエンコードとデコードを通じて、パフォーマンスに重点を置いていることが特徴です。
gRPCの一番の利点は、パフォーマンスが出ることです。
RESTと比べるとデータを受信するときは7倍早く、特定のペイロードのデータを送信するときは10倍高速とも言われています。
リアルタイムストリーミングをおこなうことが可能です。
軽量で効率的なメッセージ通信を必要とする通信サービスに役立ちます。
gRPCは、ブラウザで完全にサポートされていないHTTP/2を必要とします。
HTTP/2が使える環境でないと使うことができないため、プライベートなAPIでの利用が主になります。
gRPC は、リソースの少ないデバイス間の通信などでよく使用されます。
たとえば、IoT デバイス、スマートデバイス、カメラは、最小限のリソースを使用してパフォーマンスを最適化するため、gRPC を使用することでメリットを得ることができます。
また、gRPC は、異なる言語で記述されたサービスと通信できるため、マイクロサービスアーキテクチャのサービス間の通信でも度々用いられます。
まとめると、gRPCは下記のケースに適しています。
ここまでREST、GraphQL、gRPCの違いとユースケースを紹介してきました。
実際にプロダクトに導入を検討する際には、下記のようなことも考慮してみてください。
初期段階では、概念実証をおこなってスモールスタートから実施していくことがオススメです。
この記事を通じて適切な設計手法でAPI開発を進めていける手助けになれば幸いです。
クランチタイマーでは、REST、GraphQL、gRPCを使った開発をおこなうことができます。
API設計でお悩みがあれば、お気軽にご相談頂ければと思います!
ここまでご覧頂きありがとうございました!
SHARE:
お気軽にお問い合わせください。
TEL082-236-1186
代表の佐々⽊が⽉に1回お届けするメールマガジン。
国内外スタートアップの最新情報や最新技術のサマリー、クランチタイマーの開発事例紹介など、ITに関する役⽴つ情報を中⼼にお送りします!