リクエストをつなぐ
一度サインインしてトークンを保存し、必要なすべてのリクエストから送ります。動的な値とIdempotency-Keyも使います。
多くのAPIでは、サインインして取得したトークンが必要です。このチュートリアルでは、デモショップのトークンをサインインのレスポンスから変数に保存し、フォルダの認証を通じてフォルダ全体から送り、あるレスポンスの値を次のリクエストで読み取り、Idempotency-Keyで安全に注文します。
- 所要時間:15分。
- 必要なもの:最初のワークスペースで作ったワークスペース。Demo環境を選び、Auth › Sign inリクエストがあること。Alpenglowにはこれらがすべて用意されています。比較のために開いてみてください。
- 学べること:レスポンスからのキャプチャ、継承される認証、動的な値、レスポンスの値。
1. サインインのレスポンスからトークンを保存する
- Auth › Sign inを開いて送信します(⌘R)。
- レスポンスのボディタブで、表示をJSONツリーに切り替えます。
access_tokenの行にポインタを重ねます。値の後ろに小さなボタンが現れます。ヘルプに変数に保存…と表示されるものを選びます。- 変数に保存ポップオーバーで:
- 名前を
tokenに変更します。 - スコープで環境「Demo」を選びます。サーバごとにトークンが異なります。
- シークレット · キーチェーンに保存、ファイルには保存されませんがオンになっていることを確認します。
tokenのような名前では、Echolotが自動でオンにします。 - 送信のたびに更新 · このリクエストと一緒に保存はオンのままにします。
- 名前を
- 保存を選びます。
リクエストの変数タブを開きます。レスポンスからの下に1行あります。token、JSONから、パス$.access_token、Demoに保存、シークレット。
以降は、Sign inの送信が成功するたびに、新しいトークンが{{token}}に書き込まれます。400以上のレスポンスや、値のないレスポンスでは、変数は変更されません。詳しくはレスポンスのキャプチャを参照してください。

2. フォルダ全体からトークンを送る
リクエストごとにBearer認証を設定する代わりに、フォルダに1回設定します。
Ordersフォルダを作ります(⇧⌘N)。- Ordersを右クリックして、フォルダ設定…を選びます。
- 認証タブで、種類をBearerトークンに、トークンを
{{token}}にします。完了を選びます。 - Ordersを右クリックして新規リクエストを選び、
List ordersという名前にします。URLを{{baseURL}}/ordersにします。 - その認証タブを開きます。種類は継承で、使用の行に、フォルダのBearerトークンを使うと表示されます。
- 送信します。
Heidiの3件の注文が返ります。ord_7Hk2Lw(発送済み)、ord_8Jm4Qx(支払い済み)、ord_5Fd9Ra(配達済み)です。
Ordersの新しいリクエストはすべて、同じようにトークンを送ります。リクエストは継承で始まり、最も近いフォルダの認証、次にワークスペースの認証を使います。ほかの種類は認証を参照してください。
後で401 Unauthorizedが返ったら、トークンの期限が切れています。有効期間は1時間です。Sign inをもう一度送信すると、トークンが更新されます。
3. ほかのレスポンスから値を読み取る
次のリクエストは、List ordersのレスポンスから最初の注文のidを読み取るので、手でコピーする必要がありません。
- Ordersに
Get orderリクエストを作ります。 - URLフィールドに
{{baseURL}}/orders/と入力し、続けて{{$responseと入力します。一覧のレスポンスグループに動的な値が表示されます。JSONPathで絞り込んだレスポンスを選びます。 - 開いたフォームで、リクエストをList ordersリクエスト(
orders/list-orders)に、JSONPathを$.items[0].idにします。まだレスポンスがないときは先に送信のままにします。完了を選びます。
URLには、{{$responseJSONPath('orders/list-orders', '$.items[0].id')}}を表すトークンが入ります。ポインタを重ねると、現在の値ord_7Hk2Lwが表示されます。
Get orderを送信すると、その注文が明細と配送先とともに返ります。List ordersがまだ一度も送信されていなければ、Echolotが先にそれを送信します。
4. 動的な値を使って注文する
動的な値は、送信のたびに新しく作られます。新しい注文で2つ使います。
-
Ordersに、メソッドPOST、URL
{{baseURL}}/ordersのCreate orderリクエストを作ります。 -
ボディタブでJSONを選び、ボディを入力します。
{{の一覧からISO 8601タイムスタンプを挿入します。{ "lines": [ { "sku": "TNT-MH-2P", "quantity": 1 }, { "sku": "PCK-TIT-30", "quantity": 2 } ], "note": "Placed from Echolot at {{$isoTimestamp}}" } -
ヘッダータブで、
Idempotency-Keyヘッダーを追加します。値には{{と入力して、UUID({{$uuid}})を選びます。 -
送信します。
レスポンスは201 Createdで、/v1/orders/ord_…のようなLocationヘッダーが付き、ショップはIdempotency-Keyをそのまま返します。noteには送信時刻が入ります。デモは何も保存しないため、新しい注文を後から取得することはできません。
すべての動的な値はリファレンスにあります。

5. Idempotency-Keyの働きを確かめる
Idempotency-Keyは、同じキーでの送信は同じ注文であることをサーバに伝えます。そのため、もう一度送信しても注文が二重にならないようにできます。
- Create orderをもう一度送信します。
Locationのidが変わります。{{$uuid}}が新しいキーを作ったためです。 - ヘッダータブで、
{{$uuid}}をtutorial-order-1のような固定の値に置き換えます。 - 2回送信します。どちらのレスポンスにも、同じ注文idが入っています。
実際のAPIでは、最初の送信が実は届いていた場合に、繰り返されたリクエストを破棄するためにこのキーを使います。Echolotも使います。
開いたままの接続が、応答の前に閉じられた場合、Echolotは、2回送っても害がないときにだけ、リクエストを新しい接続で再送します。GET、PUT、DELETEなどの安全または冪等なメソッド、およびIdempotency-Keyヘッダーのあるリクエストが該当します。
キーのないPOSTは再送せずに失敗するので、知らない間に注文が二重になることはありません。終わったら、{{$uuid}}に戻してください。
ショップが確認することがもう2つあります。
- 数量を
0に変更して送信します。422 Unprocessable Contentが、各明細の問題点を示します。 - AlpenglowのOrders with OAuth 2は、クライアント資格情報でトークンを取得します。このトークンで注文を読み取ることはできますが、作成はできません。それで
POST /v1/ordersを送ると403 Forbiddenが返ります。
次のステップ
- APIをテストしてCIで実行する:チェックを追加し、チェーン全体を一度に実行します。
- スクリプトとテスト:キャプチャでは足りない場合の
pm.environment.set()など。 - OAuth 2.0とその他の認証タイプ:Echolotにトークンの取得と更新を任せます。

