Representational State Transfer API

定義

REST API（Representational State Transfer API）とは、HTTPプロトコルの設計思想に基づいて構築された、システム間連携のための標準的なインターフェース仕様です。ロイ・フィールディングが2000年の博士論文で提唱したアーキテクチャスタイルを起源とし、現在ではDTC（Direct-to-Consumer）・EC・広告運用の現場において、注文・在庫・広告データをリアルタイムで同期するための事実上の業界標準となっています。

RESTの核心は「リソース（資源）をURIで一意に識別し、HTTPメソッド（GET / POST / PUT / DELETE）で操作する」という点にあります。たとえばShopifyの注文データは /admin/api/2024-01/orders.json というURIで表現され、新規注文の取得はGET、在庫更新はPUT、返品処理はDELETEといった具合に、直感的な操作が可能です。

类比：REST APIは「レストランのメニュー表」

REST APIを理解する最もわかりやすい比喩は、レストランの注文システムです。

- URI = メニューに載っている料理名（「カルボナーラ」「在庫一覧」）

- HTTPメソッド = 店員への指示（「見せて」=GET、「作って」=POST、「交換して」=PUT、「下げて」=DELETE）

- ステータスコード = 店員の返答（200=「はい、どうぞ」、404=「品切れです」、500=「厨房トラブル」）

- JSON = 料理が載ったお皿（データの入れ物）

この比喩の利点は、「同じリソースに対して異なる動詞を組み合わせる」というRESTの本質を直感的に掴める点です。EC現場では、この「メニュー表」がShopify・WooCommerce・BASE・Amazon SP-APIなど各プラットフォームごとに用意されており、開発者は仕様書（APIドキュメント）を見ながら「どのメニューを、どの動詞で呼ぶか」を設計します。

公式・構造

REST APIの基本構造は、以下の4要素で表現できます。

リクエスト = HTTPメソッド + URI + ヘッダー + ボディ
レスポンス = ステータスコード + ヘッダー + ボディ（JSON/XML）

具体的な在庫同期の例：

PUT https://api.example-shop.com/v1/inventory/SKU-12345
Headers: { "Authorization": "Bearer xxxxx", "Content-Type": "application/json" }
Body: { "quantity": 87, "location": "tokyo-warehouse" }

→ Response: 200 OK
{ "sku": "SKU-12345", "quantity": 87, "updated_at": "2024-11-15T10:23:00Z" }

レート制限も重要な公式要素です。たとえばShopifyは「1秒あたり2リクエスト（バースト40）」、Amazon SP-APIは「1秒あたり0.5リクエスト」といった具合に、プラットフォームごとに上限が定められています。DTC事業者が1日に10,000件の注文を処理する場合、単純計算で約1.4時間〜5.5時間の同期時間が必要となり、バッチ設計が不可欠です。

比較表：REST vs 他のAPI方式

項目	REST API	GraphQL	SOAP	Webhook
通信方式	HTTPリクエスト/レスポンス	HTTP（単一エンドポイント）	HTTP/XML	サーバー Push
データ形式	JSON（主流）	JSON	XML	JSON
取得単位	リソース単位	フィールド指定可	メソッド単位	イベント単位
リアルタイム性	ポーリング必要	ポーリング必要	ポーリング必要	即時
学習コスト	低	中	高	低
DTCでの用途	注文・在庫同期	複雑な商品検索	基幹システム連携	注文通知・在庫変動
代表例	Shopify, BASE	Shopify Storefront	楽天RMS（一部）	Shopify Orders/Create

DTC現場では「REST APIで定期同期 + Webhookで即時通知」のハイブリッド構成が最も一般的です。たとえば在庫切れリスクを避けるには、Webhookで「注文作成」イベントを受信し、即座にREST APIで在庫を1減算する、というフローが定石です。

応用シーン

1. 注文同期（Order Sync）

Shopify → 基幹システム（kintone、Salesforce等）への注文転送。1日500件の注文を15分間隔でポーリングする場合、1回あたり約33件の差分取得が必要です。

2. 在庫同期（Inventory Sync）

複数モール（Shopify・Amazon・楽天）の在庫を一元管理。SKU数3,000点を毎時同期する場合、レート制限2req/秒の環境では約25分で全件更新が完了します。

3. 広告データ連携（Ad Sync）

Meta Ads・Google Ads・TikTok Adsのインプレッション・コンバージョンをREST APIで取得し、Looker Studioで可視化。日次でCPA・ROASを自動集計することで、翌朝の予算調整が可能になります。

4. 顧客管理（CRM連携）

購入履歴・LTV・セグメント情報をREST API経由でCRMに同期し、RFM分析に基づくメルマガ配信を自動化。

よくある誤解

誤解1：「REST API = JSON API」

→ RESTはあくまでアーキテクチャスタイルであり、データ形式はJSON・XML・YAMLいずれも可。ただし実務上はJSONが99%です。

誤解2：「POSTは常に新規作成」

→ POSTは「非冪等な操作」全般を指し、検索やバッチ処理にも使われます。冪等性が必要な更新はPUT/PATCHを使います。

誤解3：「ステータスコード200なら成功」

→ 200でもレスポンスボディにエラー情報が含まれるケース（部分成功）があります。必ずボディも検証しましょう。

誤解4：「APIキーをフロントエンドに埋め込んでよい」

→ 絶対にNGです。DTC現場ではOAuth 2.0またはサーバーサイドプロキシ経由での呼び出しが必須です。

誤解5：「レート制限は気にしなくてよい」

→ 超過すると429 Too Many Requestsが返り、最悪の場合APIキーが停止されます。指数バックオフ（Exponential Backoff）実装が推奨されます。