2023年のAPIプロトコルの現状

xguru · 2023-12-05T10:14:02+09:00

Postmanが4万人の開発者を対象にした調査を通じて整理した、APIプロトコルのトレンドと長所・短所 REST、WebHooks、GraphQL、SOAP、WebSocket、gRPCなど REST 依然として最も広く使われている。過去2年間で92%から86%に減少シンプルさ、拡張性、そしてWebサービスとの統合のしやすさ RESTの長所シンプルさと標準化: 標準的なHTTPメソッドを利用するため、すでにHTTPに慣れている開発者が容易に採用できる。シンプルさは迅速な学習と統合を促進する拡張性: RESTのステートレスな特性により、サーバーはリクエスト間でセッションデータを保存する必要がない。共有サーバーなしでインスタンスを追加でき、水平スケーリングを容易にするパフォーマンス: ステートレスでキャッシュ可能なレスポンスは実行速度を高め、リクエスト数を減らしてくれるモジュール性: RESTfulサービスはモジュール式コンポーネントとして開発できる。独立した更新を可能にし、保守性を向上させるプラットフォーム非依存: さまざまなクライアントで利用可能。相互運用性がシステム全体にわたるAPI統合を促進する成熟したツールとコミュニティのサポート: ツール、ライブラリ、ベストプラクティス、問題解決ガイド、コミュニティリソースが豊富 RESTの課題オーバーフェッチ & アンダーフェッチ: クライアントがデータの一部だけを必要とすることがあり、必要以上または不足したデータを取得してしまう場合がある。これによりパフォーマンス問題が発生し、帯域幅が無駄になる可能性がある複数回のインターフェース呼び出し: 関連データを取得するには複数のリクエストが必要になる場合があり、その結果レイテンシが増える。こうした連続呼び出しは、アプリケーションの拡大に伴って問題になりうるバージョン管理の問題: REST APIの新しいバージョンを作成するのは煩雑になりがちで、特にデータ構造やサービス機能が変わる場合はなおさらである。その結果、旧バージョンとの互換性問題がしばしば発生するステートレスゆえのオーバーヘッド: ステートレスは拡張性を支える一方で、すべてのリクエストに必要なコンテキストを毎回提供しなければならないことも意味する。特にクライアントが大量の繰り返しデータを送る必要がある場合、オーバーヘッドの原因となるリアルタイム機能の不足: RESTはチャットやライブフィードのようなリアルタイムアプリには最適化されていない。WebSocketやSSEのほうがこうしたユースケースに適している WebHooks WebHookは、ソースアプリケーションのイベントによってトリガーされるカスタムHTTPコールバックイベントが発生すると、ソースアプリケーションは対象アプリケーションが指定したURIへHTTPリクエスト（通常はPOST）を送信し、これによって反復的なポーリングなしでほぼリアルタイムのイベント駆動通信が可能になる WebHookはますます人気を集めており、開発者の36%がさまざまなシステム間の円滑な統合のために利用している WebHooksの長所リアルタイム通信: WebHookによりリアルタイムのデータ送信が可能。イベントが発生するとそのデータが送られ、システム間の最新の同期が保証される効率性: WebHookはリソース集約的なポーリングを排除し、計算性能と帯域幅を節約する柔軟性: WebHookは特定のイベントに応答するよう設定できるため、あるアプリケーションのどの操作やトリガーが別のアプリケーションへデータを送るかをカスタマイズできる統合の簡素化: HTTPメソッドを使うため、ほとんどのアプリケーションで簡単に利用できる疎結合アーキテクチャの支援: WebHookはイベントを基盤に動作するため、自然にイベント中心または疎結合のアーキテクチャを支え、モジュール性と拡張性を高める WebHooksの課題エラー処理: WebHookの受信側がダウンしていたり、コールバック処理でエラーが発生した場合、データ損失のリスクがある。WebHookを使うシステムには、再試行やログを含む堅牢なエラー処理メカニズムが必要セキュリティ問題: WebHookはインターネット経由でデータを送信するため、データの盗聴や悪意ある攻撃に弱くなりうる。HTTPSやペイロード署名の利用といったAPIセキュリティ対策が不可欠複数のWebHook管理: WebHookの管理と監視は複雑になりうる。特にアプリケーションが成長し、複数のWebHookに依存し始めるとその傾向が強まる。すべてのWebHookが正しく動作していることを確認し、さまざまなエンドポイントを追跡するには注意が必要過負荷の可能性: 大量の同時コールバックによりアプリケーションの受信側に負荷がかかることがあるが、レート制限やバッチ処理は急増の管理に役立つ可能性がある GraphQL GraphQLはAPI向けのクエリ言語であり、データに対して定義された型システムを使ってクエリを実行するためのサーバーサイドランタイムでもある 2012年にFacebookが開発し、2015年にオープンソースプロジェクトとして公開されたGraphQLは、既存のREST APIに対するより柔軟で効率的な代替手段を提供する GraphQLは開発者の間で採用率が29%まで上昇しており、今日のAPI環境における重要性を示している関連データを取得するために複数のAPIエンドポイントをまたぐ必要があるRESTとは異なり、GraphQLを使えば単一のクエリで必要なすべてのデータを取得できるこれはデータ取得プロセスへのより大きな制御権を提供し、より動的で応答性の高いユーザーインターフェースを作れるため、特にフロントエンド開発者に有用 GraphQLの長所強力な型付きスキーマ: GraphQL APIには強い型付けのスキーマがあるため、開発者はクエリに利用できるデータと型を正確に把握できる正確なデータ取得: クライアントは必要なデータを正確に要求でき、オーバーフェッチやアンダーフェッチの問題を解決し、さらにパフォーマンス向上とコスト削減にもつながるクエリの複雑性と多様なリソース: GraphQLは1回のリクエストで複数のデータ型へのクエリをサポートするため、複雑で相互に関連するデータに対するネットワークリクエスト数を減らせるサブスクリプションによるリアルタイム更新: GraphQLはサブスクリプションを通じてリアルタイム同期をサポートし、クライアントをリアルタイムで更新できるイントロスペクション: GraphQLの自己文書化スキーマにより、自己検査を通じてより容易に開発できる GraphQLの課題クエリの複雑性: GraphQLがクライアントにもたらす柔軟性には欠点もある。過度に複雑または入れ子になったクエリはパフォーマンスに悪影響を与える可能性があるため学習曲線: GraphQLはミューテーションやサブスクリプションといった新しい概念のため、RESTより学習曲線が急であるバージョン管理: クエリの柔軟な性質により、スキーマ変更が既存クエリを壊し、バージョン管理を複雑にする可能性があるリソースの過剰使用の可能性: クライアントは1つのクエリで複数のリソースを要求できるため、必要以上のデータを取得してサーバーに過負荷をかけるリスクがあるセキュリティ問題: 悪意のある利用者がGraphQLの柔軟性を悪用し、複雑なクエリでサーバーに過負荷を与える可能性がある SOAP SOAP(Simple Object Access Protocol)は、Webサービスを実装するために構造化情報を交換するためのプロトコルメッセージ形式としてXMLを使用し、通常はメッセージ交渉および転送レイヤーとしてHTTPまたはSMTPを使用する RESTやGraphQLとは異なり、SOAPにはACID準拠トランザクション、セキュリティ、メッセージングパターンといった厳格な標準と組み込み機能がある利用率が開発者の26%にとどまり減少しているにもかかわらず、SOAPは特定のアプリケーションにおいて信頼できる選択肢 SOAPの長所強力な型付けと契約: WDSL(Web Services Description Language)文書で定義された強い型付けと厳格な契約がある組み込みのセキュリティ機能: SOAPはWS-Security標準を通じて実装される認証、認可、暗号化により包括的なセキュリティを提供する。そのためエンタープライズアプリケーションで好まれる選択肢となっている ACIDトランザクション: SOAPは、金融や医療システムのようにデータ整合性が重要なアプリケーションに不可欠なACIDトランザクションをサポートする信頼性の高いメッセージング: SOAPは確実なメッセージ配信を保証し、エラー処理にも優れているため、メッセージ配信保証が重要なシステムに非常に適している言語・プラットフォーム・転送中立性: RESTと同様、SOAPサービスは基盤となるプログラミング言語、プラットフォーム、転送プロトコルに関係なく、XMLを理解するすべてのクライアントから利用できる SOAPの課題複雑さと学習曲線: SOAPは厳格な標準とXMLの使用により実装がより複雑になりうるため、RESTやGraphQLのような代替手段より学習曲線が急である詳細なメッセージ: SOAPメッセージヘッダーは多くのオーバーヘッドを伴うため、RESTやGraphQLのJSONよりペイロードが大きくなる。これはパフォーマンスや帯域幅使用量に影響する可能性がある限られたコミュニティサポート: SOAPは存在感を失いつつあり、それはコミュニティサポートや利用可能なライブラリが減少していることを意味する柔軟性の低さ: 契約が変更されると、クライアントとサーバーの双方がそれぞれの実装を更新する必要が生じる場合があり、これは欠点になりうるファイアウォールの問題: SOAPはHTTP/HTTPSとは異なる転送プロトコルを使う場合があり、その結果ファイアウォール制限に直面することがある。これにより一部のデプロイ環境ではSOAPの汎用性が低下する WebSocket WebSocketはクライアントとサーバー間で持続的かつ低レイテンシな双方向接続を提供し、リアルタイムデータ転送を可能にする HTTPのリクエスト・レスポンス周期とは異なり、WebSocketを使えばサーバーは初期ハンドシェイク後いつでもクライアントへデータを送れるチャットアプリケーション、オンラインゲーム、取引プラットフォームなどで即時のデータ更新を容易にする調査によると、開発者の25%がWebSocketを使用している WebSocketの長所リアルタイム双方向通信: リアルタイム双方向通信は、やり取りのたびに再確立が必要なHTTP接続よりレイテンシが低いオーバーヘッドの削減: 初期ハンドシェイク後も接続が開いたまま維持されるため、従来のHTTPリクエストに伴うヘッダーのオーバーヘッドが減るリソースの効率的な利用: 永続接続はロングポーリングよりもサーバーリソースを効率的に使う WebSocketの課題実装の複雑さ: WebSocketの実装は他のAPIアーキテクチャより複雑で時間がかかる可能性がある。特にWebSocketがサポートされない環境で代替手段の必要性を考えるとその傾向が強い組み込み機能の不足: セキュリティやトランザクション向けの機能が組み込まれているSOAPとは異なり、WebSocketはより基本的な仕組みに近く、開発者がそれらの機能を自ら実装しなければならないリソース消費: オープンなWebSocket接続は一般にロングポーリング技術より効率的だが、それでもサーバーリソースを消費し、大規模では問題になりうるネットワーク制限: 一部のプロキシやファイアウォールはWebSocketをサポートしていないため、特定のネットワーク環境では接続問題が生じる可能性がある gRPC 「Google Remote Procedure Call」を意味するgRPCは、サービス間通信を容易にする最新の高性能プロトコル HTTP/2の上に構築され、Protocol Buffersを活用してサービスメソッドとメッセージ形式を定義する GETやPOSTのような標準HTTP動詞を使うREST APIとは異なり、gRPCはサービス内でプログラミング言語の機能に近いカスタムメソッドを公開できるようにする gRPCの長所パフォーマンス: HTTP/2とProtocol Buffersを使うことで、gRPCは低レイテンシと高スループットを実現できる強い型付け: SOAPやGraphQLと同様に、gRPCも強い型付けを備えている。その結果、型がコンパイル時に検証されるためバグが減る多言語サポート: gRPCはGo、Java、C#、Node.jsを含むさまざまなプログラミング言語を高い水準でサポートするストリーミング: gRPCは即時のストリーミングリクエストとレスポンスを処理できるため、長期接続やリアルタイム更新のような複雑なユースケースに適用できるバッテリー同梱: gRPCは負荷分散、再試行、タイムアウトのような重要機能を直接サポートする gRPCの課題ブラウザサポート: ブラウザのネイティブgRPCサポートは依然として限定的であり、Webアプリケーションにおけるクライアント・サーバー間の直接通信には向いていない学習曲線: 開発者はProtocol Buffers、カスタムサービス定義、その他のgRPC機能の使い方を学ぶ必要があり、初期の生産性を下げる可能性があるデバッグの複雑さ: Protocol Buffersは人間が読める形式ではないため、gRPC APIはJSON APIよりデバッグやテストが難しいその他のAPIプロトコル MQTT : IoTのような低帯域幅ネットワークに最適化された軽量メッセージングプロトコル。クライアントはブローカーを通じてメッセージを発行・購読できるが、一部のセキュリティ機能や拡張性機能が不足している AMQP : 信頼性の高いメッセージ配信と柔軟なメッセージルーティングを保証する、より強力なエンタープライズメッセージング標準。ただし、軽量プロトコルより複雑でオーバーヘッドも大きい可能性がある SSE : HTTPを通じた単方向のサーバー・クライアント通信を可能にし、リアルタイム更新には適しているが双方向機能が不足している EDI : 発注書や請求書などの電子文書を標準化してB2Bコミュニケーションを自動化するが、初期コストが高く複雑なインフラも必要 EDA : コンポーネントがイベントに反応するイベント駆動アーキテクチャを促進し、拡張可能だがデバッグが複雑なリアルタイムシステムを可能にする結論開発者が新しいアーキテクチャ、プロトコル、ツールを採用するにつれて、API環境は継続的に進化している RESTはシンプルさと遍在性により依然として支配的だが、GraphQLやgRPCのような代替手段は、オーバーフェッチや冗長なインターフェースのような課題を解決することで注目を集めているまた開発者は、リアルタイム通信への要求のため、WebHooksやWebSocketをますます重要視している多くの一般的なAPIユースケースにおいて、RESTは拡張性、相互運用性、導入のしやすさを踏まえた堅実な基本アプローチであり続けている。また、コミュニティの成熟という利点もあるそれでも、すべてのプロトコルには長所と短所があり、アプリケーションがより複雑になるにつれて、開発者はGraphQLやgRPCのような特化型ソリューションも含めてAPIプロトコルのツールキットを賢く拡張しているあらゆるケースに当てはまる画一的な万能薬を求めるよりも、API開発者は複数のプロトコルの強みと弱みを理解することが最も重要 REST、WebHook、WebSocket、GraphQL、およびそれぞれ独自の利点を持つその他のアプローチを組み合わせたシステムを設計することで、開発者は強力で効率的かつ保守可能なAPIを構築できる個々のプロトコルの人気は今後も変動し続けるだろうが、最も重要なトレンドはAPI環境における多様性の増加である開発者は最適なAPIソリューションを作るために、このマルチプロトコルの哲学を受け入れるべきである

(blog.postman.com)

21 ポイント投稿者 xguru 2023-12-05 | 3件のコメント | WhatsAppで共有

Postmanが4万人の開発者を対象にした調査を通じて整理した、APIプロトコルのトレンドと長所・短所
REST、WebHooks、GraphQL、SOAP、WebSocket、gRPCなど

REST

依然として最も広く使われている。過去2年間で92%から86%に減少
シンプルさ、拡張性、そしてWebサービスとの統合のしやすさ
RESTの長所
- シンプルさと標準化: 標準的なHTTPメソッドを利用するため、すでにHTTPに慣れている開発者が容易に採用できる。シンプルさは迅速な学習と統合を促進する
- 拡張性: RESTのステートレスな特性により、サーバーはリクエスト間でセッションデータを保存する必要がない。共有サーバーなしでインスタンスを追加でき、水平スケーリングを容易にする
- パフォーマンス: ステートレスでキャッシュ可能なレスポンスは実行速度を高め、リクエスト数を減らしてくれる
- モジュール性: RESTfulサービスはモジュール式コンポーネントとして開発できる。独立した更新を可能にし、保守性を向上させる
- プラットフォーム非依存: さまざまなクライアントで利用可能。相互運用性がシステム全体にわたるAPI統合を促進する
- 成熟したツールとコミュニティのサポート: ツール、ライブラリ、ベストプラクティス、問題解決ガイド、コミュニティリソースが豊富
RESTの課題
- オーバーフェッチ & アンダーフェッチ: クライアントがデータの一部だけを必要とすることがあり、必要以上または不足したデータを取得してしまう場合がある。これによりパフォーマンス問題が発生し、帯域幅が無駄になる可能性がある
- 複数回のインターフェース呼び出し: 関連データを取得するには複数のリクエストが必要になる場合があり、その結果レイテンシが増える。こうした連続呼び出しは、アプリケーションの拡大に伴って問題になりうる
- バージョン管理の問題: REST APIの新しいバージョンを作成するのは煩雑になりがちで、特にデータ構造やサービス機能が変わる場合はなおさらである。その結果、旧バージョンとの互換性問題がしばしば発生する
- ステートレスゆえのオーバーヘッド: ステートレスは拡張性を支える一方で、すべてのリクエストに必要なコンテキストを毎回提供しなければならないことも意味する。特にクライアントが大量の繰り返しデータを送る必要がある場合、オーバーヘッドの原因となる
- リアルタイム機能の不足: RESTはチャットやライブフィードのようなリアルタイムアプリには最適化されていない。WebSocketやSSEのほうがこうしたユースケースに適している

WebHooks

WebHookは、ソースアプリケーションのイベントによってトリガーされるカスタムHTTPコールバック
イベントが発生すると、ソースアプリケーションは対象アプリケーションが指定したURIへHTTPリクエスト（通常はPOST）を送信し、これによって反復的なポーリングなしでほぼリアルタイムのイベント駆動通信が可能になる
WebHookはますます人気を集めており、開発者の36%がさまざまなシステム間の円滑な統合のために利用している
WebHooksの長所
- リアルタイム通信: WebHookによりリアルタイムのデータ送信が可能。イベントが発生するとそのデータが送られ、システム間の最新の同期が保証される
- 効率性: WebHookはリソース集約的なポーリングを排除し、計算性能と帯域幅を節約する
- 柔軟性: WebHookは特定のイベントに応答するよう設定できるため、あるアプリケーションのどの操作やトリガーが別のアプリケーションへデータを送るかをカスタマイズできる
- 統合の簡素化: HTTPメソッドを使うため、ほとんどのアプリケーションで簡単に利用できる
- 疎結合アーキテクチャの支援: WebHookはイベントを基盤に動作するため、自然にイベント中心または疎結合のアーキテクチャを支え、モジュール性と拡張性を高める
WebHooksの課題
- エラー処理: WebHookの受信側がダウンしていたり、コールバック処理でエラーが発生した場合、データ損失のリスクがある。WebHookを使うシステムには、再試行やログを含む堅牢なエラー処理メカニズムが必要
- セキュリティ問題: WebHookはインターネット経由でデータを送信するため、データの盗聴や悪意ある攻撃に弱くなりうる。HTTPSやペイロード署名の利用といったAPIセキュリティ対策が不可欠
- 複数のWebHook管理: WebHookの管理と監視は複雑になりうる。特にアプリケーションが成長し、複数のWebHookに依存し始めるとその傾向が強まる。すべてのWebHookが正しく動作していることを確認し、さまざまなエンドポイントを追跡するには注意が必要
- 過負荷の可能性: 大量の同時コールバックによりアプリケーションの受信側に負荷がかかることがあるが、レート制限やバッチ処理は急増の管理に役立つ可能性がある

GraphQL

GraphQLはAPI向けのクエリ言語であり、データに対して定義された型システムを使ってクエリを実行するためのサーバーサイドランタイムでもある
2012年にFacebookが開発し、2015年にオープンソースプロジェクトとして公開されたGraphQLは、既存のREST APIに対するより柔軟で効率的な代替手段を提供する
GraphQLは開発者の間で採用率が29%まで上昇しており、今日のAPI環境における重要性を示している
関連データを取得するために複数のAPIエンドポイントをまたぐ必要があるRESTとは異なり、GraphQLを使えば単一のクエリで必要なすべてのデータを取得できる
これはデータ取得プロセスへのより大きな制御権を提供し、より動的で応答性の高いユーザーインターフェースを作れるため、特にフロントエンド開発者に有用
GraphQLの長所
- 強力な型付きスキーマ: GraphQL APIには強い型付けのスキーマがあるため、開発者はクエリに利用できるデータと型を正確に把握できる
- 正確なデータ取得: クライアントは必要なデータを正確に要求でき、オーバーフェッチやアンダーフェッチの問題を解決し、さらにパフォーマンス向上とコスト削減にもつながる
- クエリの複雑性と多様なリソース: GraphQLは1回のリクエストで複数のデータ型へのクエリをサポートするため、複雑で相互に関連するデータに対するネットワークリクエスト数を減らせる
- サブスクリプションによるリアルタイム更新: GraphQLはサブスクリプションを通じてリアルタイム同期をサポートし、クライアントをリアルタイムで更新できる
- イントロスペクション: GraphQLの自己文書化スキーマにより、自己検査を通じてより容易に開発できる
GraphQLの課題
- クエリの複雑性: GraphQLがクライアントにもたらす柔軟性には欠点もある。過度に複雑または入れ子になったクエリはパフォーマンスに悪影響を与える可能性があるため
- 学習曲線: GraphQLはミューテーションやサブスクリプションといった新しい概念のため、RESTより学習曲線が急である
- バージョン管理: クエリの柔軟な性質により、スキーマ変更が既存クエリを壊し、バージョン管理を複雑にする可能性がある
- リソースの過剰使用の可能性: クライアントは1つのクエリで複数のリソースを要求できるため、必要以上のデータを取得してサーバーに過負荷をかけるリスクがある
- セキュリティ問題: 悪意のある利用者がGraphQLの柔軟性を悪用し、複雑なクエリでサーバーに過負荷を与える可能性がある

SOAP

SOAP(Simple Object Access Protocol)は、Webサービスを実装するために構造化情報を交換するためのプロトコル
メッセージ形式としてXMLを使用し、通常はメッセージ交渉および転送レイヤーとしてHTTPまたはSMTPを使用する
RESTやGraphQLとは異なり、SOAPにはACID準拠トランザクション、セキュリティ、メッセージングパターンといった厳格な標準と組み込み機能がある
利用率が開発者の26%にとどまり減少しているにもかかわらず、SOAPは特定のアプリケーションにおいて信頼できる選択肢
SOAPの長所
- 強力な型付けと契約: WDSL(Web Services Description Language)文書で定義された強い型付けと厳格な契約がある
- 組み込みのセキュリティ機能: SOAPはWS-Security標準を通じて実装される認証、認可、暗号化により包括的なセキュリティを提供する。そのためエンタープライズアプリケーションで好まれる選択肢となっている
- ACIDトランザクション: SOAPは、金融や医療システムのようにデータ整合性が重要なアプリケーションに不可欠なACIDトランザクションをサポートする
- 信頼性の高いメッセージング: SOAPは確実なメッセージ配信を保証し、エラー処理にも優れているため、メッセージ配信保証が重要なシステムに非常に適している
- 言語・プラットフォーム・転送中立性: RESTと同様、SOAPサービスは基盤となるプログラミング言語、プラットフォーム、転送プロトコルに関係なく、XMLを理解するすべてのクライアントから利用できる
SOAPの課題
- 複雑さと学習曲線: SOAPは厳格な標準とXMLの使用により実装がより複雑になりうるため、RESTやGraphQLのような代替手段より学習曲線が急である
- 詳細なメッセージ: SOAPメッセージヘッダーは多くのオーバーヘッドを伴うため、RESTやGraphQLのJSONよりペイロードが大きくなる。これはパフォーマンスや帯域幅使用量に影響する可能性がある
- 限られたコミュニティサポート: SOAPは存在感を失いつつあり、それはコミュニティサポートや利用可能なライブラリが減少していることを意味する
- 柔軟性の低さ: 契約が変更されると、クライアントとサーバーの双方がそれぞれの実装を更新する必要が生じる場合があり、これは欠点になりうる
- ファイアウォールの問題: SOAPはHTTP/HTTPSとは異なる転送プロトコルを使う場合があり、その結果ファイアウォール制限に直面することがある。これにより一部のデプロイ環境ではSOAPの汎用性が低下する

WebSocket

WebSocketはクライアントとサーバー間で持続的かつ低レイテンシな双方向接続を提供し、リアルタイムデータ転送を可能にする
HTTPのリクエスト・レスポンス周期とは異なり、WebSocketを使えばサーバーは初期ハンドシェイク後いつでもクライアントへデータを送れる
チャットアプリケーション、オンラインゲーム、取引プラットフォームなどで即時のデータ更新を容易にする
調査によると、開発者の25%がWebSocketを使用している
WebSocketの長所
- リアルタイム双方向通信: リアルタイム双方向通信は、やり取りのたびに再確立が必要なHTTP接続よりレイテンシが低い
- オーバーヘッドの削減: 初期ハンドシェイク後も接続が開いたまま維持されるため、従来のHTTPリクエストに伴うヘッダーのオーバーヘッドが減る
- リソースの効率的な利用: 永続接続はロングポーリングよりもサーバーリソースを効率的に使う
WebSocketの課題
- 実装の複雑さ: WebSocketの実装は他のAPIアーキテクチャより複雑で時間がかかる可能性がある。特にWebSocketがサポートされない環境で代替手段の必要性を考えるとその傾向が強い
- 組み込み機能の不足: セキュリティやトランザクション向けの機能が組み込まれているSOAPとは異なり、WebSocketはより基本的な仕組みに近く、開発者がそれらの機能を自ら実装しなければならない
- リソース消費: オープンなWebSocket接続は一般にロングポーリング技術より効率的だが、それでもサーバーリソースを消費し、大規模では問題になりうる
- ネットワーク制限: 一部のプロキシやファイアウォールはWebSocketをサポートしていないため、特定のネットワーク環境では接続問題が生じる可能性がある

gRPC

「Google Remote Procedure Call」を意味するgRPCは、サービス間通信を容易にする最新の高性能プロトコル
HTTP/2の上に構築され、Protocol Buffersを活用してサービスメソッドとメッセージ形式を定義する
GETやPOSTのような標準HTTP動詞を使うREST APIとは異なり、gRPCはサービス内でプログラミング言語の機能に近いカスタムメソッドを公開できるようにする
gRPCの長所
- パフォーマンス: HTTP/2とProtocol Buffersを使うことで、gRPCは低レイテンシと高スループットを実現できる
- 強い型付け: SOAPやGraphQLと同様に、gRPCも強い型付けを備えている。その結果、型がコンパイル時に検証されるためバグが減る
- 多言語サポート: gRPCはGo、Java、C#、Node.jsを含むさまざまなプログラミング言語を高い水準でサポートする
- ストリーミング: gRPCは即時のストリーミングリクエストとレスポンスを処理できるため、長期接続やリアルタイム更新のような複雑なユースケースに適用できる
- バッテリー同梱: gRPCは負荷分散、再試行、タイムアウトのような重要機能を直接サポートする
gRPCの課題
- ブラウザサポート: ブラウザのネイティブgRPCサポートは依然として限定的であり、Webアプリケーションにおけるクライアント・サーバー間の直接通信には向いていない
- 学習曲線: 開発者はProtocol Buffers、カスタムサービス定義、その他のgRPC機能の使い方を学ぶ必要があり、初期の生産性を下げる可能性がある
- デバッグの複雑さ: Protocol Buffersは人間が読める形式ではないため、gRPC APIはJSON APIよりデバッグやテストが難しい

その他のAPIプロトコル

MQTT : IoTのような低帯域幅ネットワークに最適化された軽量メッセージングプロトコル。クライアントはブローカーを通じてメッセージを発行・購読できるが、一部のセキュリティ機能や拡張性機能が不足している
AMQP : 信頼性の高いメッセージ配信と柔軟なメッセージルーティングを保証する、より強力なエンタープライズメッセージング標準。ただし、軽量プロトコルより複雑でオーバーヘッドも大きい可能性がある
SSE : HTTPを通じた単方向のサーバー・クライアント通信を可能にし、リアルタイム更新には適しているが双方向機能が不足している
EDI : 発注書や請求書などの電子文書を標準化してB2Bコミュニケーションを自動化するが、初期コストが高く複雑なインフラも必要
EDA : コンポーネントがイベントに反応するイベント駆動アーキテクチャを促進し、拡張可能だがデバッグが複雑なリアルタイムシステムを可能にする

結論

開発者が新しいアーキテクチャ、プロトコル、ツールを採用するにつれて、API環境は継続的に進化している
RESTはシンプルさと遍在性により依然として支配的だが、GraphQLやgRPCのような代替手段は、オーバーフェッチや冗長なインターフェースのような課題を解決することで注目を集めている
また開発者は、リアルタイム通信への要求のため、WebHooksやWebSocketをますます重要視している
多くの一般的なAPIユースケースにおいて、RESTは拡張性、相互運用性、導入のしやすさを踏まえた堅実な基本アプローチであり続けている。また、コミュニティの成熟という利点もある
それでも、すべてのプロトコルには長所と短所があり、アプリケーションがより複雑になるにつれて、開発者はGraphQLやgRPCのような特化型ソリューションも含めてAPIプロトコルのツールキットを賢く拡張している
あらゆるケースに当てはまる画一的な万能薬を求めるよりも、API開発者は複数のプロトコルの強みと弱みを理解することが最も重要
REST、WebHook、WebSocket、GraphQL、およびそれぞれ独自の利点を持つその他のアプローチを組み合わせたシステムを設計することで、開発者は強力で効率的かつ保守可能なAPIを構築できる
個々のプロトコルの人気は今後も変動し続けるだろうが、最も重要なトレンドはAPI環境における多様性の増加である
開発者は最適なAPIソリューションを作るために、このマルチプロトコルの哲学を受け入れるべきである

3件のコメント

zerocyber 2023-12-08

よく拝見しました

2023-12-05

[このコメントは非表示になっています。]

test191919 2023-12-07

単純な一回限りのアクションで終わる業務でないなら、トランザクションは必須ではないでしょうか？（必須なのに今になってようやくRESTを志向するというアイロニーについては共感します笑）