API Architecture

Overview

6 API Architecture Styles

SOAP

成熟(せいじゅく) した、包括的(ほうかつてき) な、XML ベース。エンタープライズアプリケーションに最適(さいてき) 。

短所(たんしょ) :

• 複雑(ふくざつ) さ
• 冗長(じょうちょう) さ

RESTful

人気(にんき) があり、実装(じっそう) が簡単(かんたん) 、HTTP メソッド。Web サービスに最適(さいてき) 。

例(れい) : Twitter、YouTube

GraphQL

クエリ言語(げんご) 、特定(とくてい) のデータを要求(ようきゅう) 。ネットワークオーバーヘッドを削減(さくげん) し、応答(おうとう) が高速(こうそく) 。

例(れい) : Meta（発明(はつめい) ）、GitHub、Shopify

短所(たんしょ) :

• 複雑(ふくざつ) なデータ要件(ようけん) を持(も) つアプリ
• 学習(がくしゅう) 曲線(きょくせん) が急(きゅう)

gRPC

最新(さいしん) の高性能(こうせいのう) 、デフォルトで Protocol Buffers を使用(しよう) 。

マイクロサービスアーキテクチャに適(てき) しています。

短所(たんしょ) : ブラウザサポートが限定的(げんていてき)

例(れい) : Netflix - 大量(たいりょう) のサービス間(かん) 通信(つうしん) を処理(しょり)

WebSocket

リアルタイム、双方向(そうほうこう) 、永続的(えいぞくてき) な接続(せつぞく) 。低遅延(ていちえん) のデータ交換(こうかん) に最適(さいてき) 。

Webhook

イベント駆動(くどう) 、HTTP コールバック、非同期(ひどうき) 。

イベントが発生(はっせい) したときにシステムに通知(つうち) します。

短所(たんしょ) : 同期(どうき) 通信(つうしん) や即時(そくじ) 応答(おうとう) が必要(ひつよう) な場合(ばあい) は、これは解決策(かいけつさく) ではないかもしれません。

例(れい) :