@spree/docs 0.1.297 → 0.1.298
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -25,6 +25,20 @@ curl -X POST https://api.mystore.com/api/v3/store/carts/cart_xxx/items \
|
|
|
25
25
|
|
|
26
26
|
If the client retries this exact request with the same idempotency key, the API returns the original response with an `Idempotent-Replayed: true` header — without adding the item again.
|
|
27
27
|
|
|
28
|
+
## Who A Cached Response Belongs To
|
|
29
|
+
|
|
30
|
+
A cached response is only ever returned to the caller that produced it, so the request has to say who that caller is. One of these identifies them:
|
|
31
|
+
|
|
32
|
+
- the **customer's access token** (`Authorization: Bearer ...`), for a signed-in shopper
|
|
33
|
+
- the **cart token** (`X-Spree-Token`), for a guest working on a cart they already hold
|
|
34
|
+
- a **secret key** (`sk_...`), for a server-to-server caller on the Admin API
|
|
35
|
+
|
|
36
|
+
Retry with the same credentials you sent the first time. A replay answers from the cache without running the request again, so it never re-checks your access — a retry that drops or swaps a credential is treated as a different caller and runs for real.
|
|
37
|
+
|
|
38
|
+
Your publishable key (`pk_...`) does not count. Every visitor to your storefront sends the same one, so a key value that two shoppers happen to share — `checkout-1`, an order number, a timestamp — would hand one shopper the other's response, cart token included.
|
|
39
|
+
|
|
40
|
+
A request that carries none of the credentials above still runs exactly as it always has — it is simply never cached, so the `Idempotency-Key` header has no effect on it. Guests are not second-class here: a guest holds a cart token from the moment their cart exists, which covers the whole of checkout, including the steps where a duplicate costs money.
|
|
41
|
+
|
|
28
42
|
## Supported Endpoints
|
|
29
43
|
|
|
30
44
|
| Endpoint | Actions |
|
|
@@ -38,13 +52,15 @@ If the client retries this exact request with the same idempotency key, the API
|
|
|
38
52
|
| `POST /carts/:id/coupon_codes` | Applying coupon codes |
|
|
39
53
|
| `POST /carts/:id/store_credits` | Applying store credits |
|
|
40
54
|
|
|
55
|
+
Every one of these is replayable for a guest as well as for a signed-in shopper, because every one of them is reached with the cart's token. The exception is creating the cart itself: there is no cart yet, so a guest has no token to present and the key is ignored — a retry may leave behind a second, empty cart. Sign the shopper in, or accept the spare cart.
|
|
56
|
+
|
|
41
57
|
Idempotency keys are ignored on `GET`, `DELETE`, and other non-supported actions.
|
|
42
58
|
|
|
43
59
|
## Key Requirements
|
|
44
60
|
|
|
45
61
|
- Must be a string of **255 characters or less**
|
|
46
62
|
- Should be unique per distinct operation (UUIDs are recommended)
|
|
47
|
-
- Keys are scoped
|
|
63
|
+
- Keys are scoped to the caller and the store, so two callers can use the same key value without conflict
|
|
48
64
|
- Cached responses expire after **24 hours**
|
|
49
65
|
|
|
50
66
|
## Response Headers
|