BLOG

ブログ

  • Top
  • Blog
  • 【WebAPI徹底比較】REST・GraphQL・gRPC設計

【WebAPI徹底比較】REST・GraphQL・gRPC設計

ブログサムネイル
Crunchtimer株式会社

著者:クランチタイマー株式会社

Twitter Icon

クランチタイマーはアプリ・Webサービスなどの開発を手掛けるWebデベロッパーです。ブログ記事ではロジカルで最適な手法を伝え、課題解決の手助けとなる情報を惜しみなく提供していきます。



近年、APIの設計手法としてGraphQLやgRPCが使われるようになってきました。

慣れ親しんだRESTを使った方が良いのか、新しい設計手法を試した方が良いのか、迷う方も多いのではないでしょうか?

この記事では、それぞれのAPI設計の特徴や、プロダクトごとに選択するべき設計手法・ユースケースについてご紹介します。

新規プロダクト開発にどの手法を用いれば良いかお困りの方は、参考にして頂ければと思います。

この記事の見出し

REST

最初に、RESTからご紹介します。

Representational State Transfer(REST) は、アプリケーション開発で最も一般的なAPI設計です。

URLを使用してリソースを指定し、HTTPメソッドを使用して実行するアクションを決定します。

HTTPメソッドには以下のような種類があります。

GET 既存のリソースを取得する
POST 新しいリソースを作成する
PUT リソースが存在する場合はリソース全体を更新し、存在しない場合は作成する
DELETE リソースを削除する
PATCH 既存のリソースを部分的に更新する

また、RESTはステートレスという特徴を持っています。

クライアントのリクエストには、サーバーがリクエストを処理するために必要なすべての情報が含まれており、サーバーはクライアントの状態を保持しません。

RESTのメリット

シンプルに使える

HTTP標準のメソッドを使用してCRUD操作を実装できます。

また、アーキテクチャを簡素化および分離する統一されたインターフェースがあります。

スケーラビリティが高い

多数のコンポーネントとそれらの間の相互作用のサポートを可能にします。

複数のアプリケーションを簡単に統合することも可能です。

RESTのデメリット

無駄なデータ取得が起こりうる

オーバーフェッチやアンダーフェッチなどで、必要のないリソースを取得することがあります。

そのため、ペイロードが大きくなりがちです。

RESTのユースケース

では、RESTはどんなプロダクトに向いているのでしょうか。

RESTは昔からあるAPIの設計手法で、さまざまなプロダクトに用いられています。

そのため、どんなプロダクトでも平均的に使いこなすことが可能です。

GraphQLやgRPCを使うメリットが特になければ、比較的どんなプロダクトにも使えるRESTを利用すれば良いでしょう。

開発に不慣れな場合にも、学習コストの低さや情報量の多さもメリットとなり得ます。

また、多くのリクエストと限られた帯域幅を処理する場合にも、RESTがお勧めです。

このような場合は、キャッシュサポートを使用してパフォーマンスを向上させることができます。

まとめると、RESTは下記のケースに適しています。

  • CRUDスタイルのWebアプリケーションを構築している。
  • APIは、主に適切に構造化された関連データを操作している。
  • APIは、キャッシュ可能である必要がある。

GraphQL

次は、GraphQLについてご紹介します。

GraphQLは、2015年に導入されたデータクエリ言語です。

これにより、開発者は必要なデータを必要な分だけ取得できます。

RESTと比較すると、GraphQLはクライアント主導のアプローチであり、必要なデータやデータの取得方法、および形式をクライアントが決定できます。

また、クライアントが必要なデータを特定できるため、RESTのデメリットであるオーバーフェッチとアンダーフェッチの問題も解決されます。

GraphQLは、主にクエリとミューテーション、サブスクリプションを使用してデータを操作します。

クエリ サーバーからデータを要求すること
ミューテーション サーバー側のデータを変更すること
サブスクリプション リアルタイムでのデータ処理

GraphQLを取り入れたプロダクトとして有名なのがGithubです。

GitHubは、2016年にRESTからGraphQLに切り替えています。

Githubのように数千万人規模のユーザーを抱え、データ取得の数が多くなるようなプロダクトには必要なデータだけ取り出せるGraphQLが適していました。

GraphQLのメリット

無駄なデータ取得がない

RESTのデメリットであるオーバーフェッチやアンダーフェッチが発生しません。

クライアントが要求するものを過剰に取得することなく正確に提供します。

データ取得が柔軟におこなえる

クライアントは、必要なデータ、必要な方法、および取得する形式を決定します。

GraphQLのデメリット

バックエンド開発の負担が増える

クライアントが柔軟にデータを取得できる一方で、サーバー側で面倒な処理をおこなう必要があります。

そのため、サーバー側の開発の負担が増します。

またサーバー側で複雑な処理をするようになると、パフォーマンスの予測も困難になることがあります。

組み込みのキャッシュサポートがない

標準でキャッシュがサポートされていません。

RESTに比べて学習コストが高い

RESTとgRPCに比べて、学習コストが高いです。

GraphQLでの開発に慣れていないと、うまく運用できない可能性があります。

GraphQLのユースケース

では、GraphQLはどのようなプロダクトに適しているのでしょうか。

GraphQLはオーバーフェッチを排除し、特定の形式で必要なデータのみを取得して、アプリケーションのパフォーマンスを向上させることができます。

そのため、データ量を管理することが重要になるスマートフォンなどのプラットフォームに適しています。

GraphQLを使用して、これらのデバイスでホストされているアプリケーションが必要とする正確なデータを返すようにすると、帯域幅の消費が削減されます。

アプリケーションがモバイルで利用されることが想定される場合は、GraphQLの利用を考えてみても良いでしょう。

また、GraphQL は複数のデータソースから応答を構築できます。

すべてのデータを 1 つの応答にネストできるため、レポートダッシュボードなどのアプリケーションにも適しています。

さらに、クライアントがAPIをどのように利用するかを完全に理解していない場合にも、GraphQLを使用できます。

GraphQLでは、事前に厳密なAPIを定義する必要はありません。

クライアントが必要とするデータが明らかになっていくにつれてAPIを徐々に構築できます。

そのため、アプリを構築しながら柔軟にデータのやりとり内容を決めていく場合にも相性が良いです。

まとめると、GraphQLは下記のケースに適しています。

  • アプリケーションが帯域幅に敏感であり、データ通信量が重要な課題になる。
  • クライアントがどのリソースを要求する必要があるかを分析する機会が得られるまで、API定義を延期したい。

gRPC

最後に、gRPCについてご紹介します。

gRPCは、Googleが開発したRPCフレームワークです。

OSSとして提供されており、言語が異なるサービス間の通信や、さまざまなプラットフォームで利用することができます。

データのシリアル化にプロトコルバッファ(Protobufs) を使用することで、非常に軽量で高速なAPIを提供します。

非常に軽量であるため、gRPC はクライアントの計算能力が限られている場合によく使われます。

gRPC は、コンパクトなデータフォーマット、トランスポート層としてのHTTP/2の使用、およびメッセージの高速なエンコードとデコードを通じて、パフォーマンスに重点を置いていることが特徴です。

gRPCのメリット

軽量で高速なためパフォーマンスが出る

gRPCの一番の利点は、パフォーマンスが出ることです。

RESTと比べるとデータを受信するときは7倍早く、特定のペイロードのデータを送信するときは10倍高速とも言われています。

ストリーミングが可能

リアルタイムストリーミングをおこなうことが可能です。

軽量で効率的なメッセージ通信を必要とする通信サービスに役立ちます。

gRPC のデメリット

デフォルトでブラウザのサポートがない

gRPCは、ブラウザで完全にサポートされていないHTTP/2を必要とします。

HTTP/2が使える環境でないと使うことができないため、プライベートなAPIでの利用が主になります。

gRPCのユースケース

gRPC は、リソースの少ないデバイス間の通信などでよく使用されます。

たとえば、IoT デバイス、スマートデバイス、カメラは、最小限のリソースを使用してパフォーマンスを最適化するため、gRPC を使用することでメリットを得ることができます。

また、gRPC は、異なる言語で記述されたサービスと通信できるため、マイクロサービスアーキテクチャのサービス間の通信でも度々用いられます。

まとめると、gRPCは下記のケースに適しています。

  • クライアントのリソースが少ない。
  • マイクロサービスアーキテクチャ間の通信などサービス同士の通信を強化したい。
  • パフォーマンスは重要な問題である。

終わりに

ここまでREST、GraphQL、gRPCの違いとユースケースを紹介してきました。

実際にプロダクトに導入を検討する際には、下記のようなことも考慮してみてください。

  • どのプログラミング言語を使いたいか。
  • このAPIにとって重要なコア機能は何か。
  • 社内でどのようなスキルを持っているか。 また、どのようなスキルを取得できるか。
  • どのようなリソースや予算があるか。

初期段階では、概念実証をおこなってスモールスタートから実施していくことがオススメです。

この記事を通じて適切な設計手法でAPI開発を進めていける手助けになれば幸いです。

クランチタイマーでは、REST、GraphQL、gRPCを使った開発をおこなうことができます。

API設計でお悩みがあれば、お気軽にご相談頂ければと思います!

ここまでご覧頂きありがとうございました!

またクランチタイマーでは、フルリモートで一緒に働くエンジニアを募集中です。

詳細は、以下のWantedlyページをご確認ください。

この記事をシェア  

link-icon

筆者

加藤 潤一

Laravel/PHP/Goでのサーバーサイド開発やスマホアプリの開発を行っております。 お客様のプロダクトの成果を最大化できるように、要件定義から一連の開発プロセスまでサポートさせて頂きます。

最新情報を確認する

CONTACT

お気軽にお問い合わせください。

TEL082-299-2286

NEWSLETTER

代表の佐々⽊が⽉に1回お届けするメールマガジン。
国内外スタートアップの最新情報や最新技術のサマリー、クランチタイマーの開発事例紹介など、ITに関する役⽴つ情報を中⼼にお送りします!