3 ms·

> Let's say a client of an HTTP API wants to create (or update) a resource using a "POST" method. Since "POST" is NOT an idempotent method (…) Use PUT i

> Let's say a client of an HTTP API wants to create (or update) a resource using a "POST" method. Since "POST" is NOT an idempotent method (…) Use PUT instead? The deterministic key that would go in the Header goes as part of the URI. I’m not seeing why standardize a roundabout way of doing the same. Am I missing something?

p4bl0 5y ago
Yes, that was my thought too. The HTTP verb PUT is specifically made for idempotency, why would HTTP need a header filed for that?
- bpicolo 5y ago
  Because the use case isn't necessarily modifying a resource. Charging somebody for a product, for example, doesn't have natural idempotency. They could buy the same item twice
  - deleted 5y ago
    [deleted]
  - p4bl0 5y ago
    Isn't that a modeling problem? Let's say you don't pay for an item but for a basket even if it has only one item. If each specific basket has its own unique id then you have a unique resource that can have a paid or not yet paid status, and use HTTP verbs appropriately against it (e.g., POST to add an item to the basket, or PUT to pay for the basket). Another basket, even with the same item(s) added to it, would have another id. Problem solved.
    - bpicolo 5y ago
      For the case of this header, you're interacting with third parties that don't speak your application domain. That "unique id" you mention is exactly the use case for the idempotency key this RFC proposes. You can model your unique basket identifier in your application domain, and use that identifier as the idempotency key in interactions with third parties. This is useful mostly because networks and applications are not necessarily reliable.
ec109685 5y ago
The semantics don’t quite work out. If you don’t know the ID of a transaction, for example, using PUT with a client derived key wouldn’t make sense given a subsequent GET would be made against the transaction ID, not the idempotency key.
- hcarvalhoalves 5y ago
  An alternative is for the client to request an ID, another is for the server to respond the PUT with a 307 Temporary Redirect to GET the resource, idempotency is transparent for the client.

p4bl0 5y ago

Yes, that was my thought too. The HTTP verb PUT is specifically made for idempotency, why would HTTP need a header filed for that?

bpicolo 5y ago
Because the use case isn't necessarily modifying a resource. Charging somebody for a product, for example, doesn't have natural idempotency. They could buy the same item twice
- deleted 5y ago
  [deleted]
- p4bl0 5y ago
  Isn't that a modeling problem? Let's say you don't pay for an item but for a basket even if it has only one item. If each specific basket has its own unique id then you have a unique resource that can have a paid or not yet paid status, and use HTTP verbs appropriately against it (e.g., POST to add an item to the basket, or PUT to pay for the basket). Another basket, even with the same item(s) added to it, would have another id. Problem solved.
  - bpicolo 5y ago
    For the case of this header, you're interacting with third parties that don't speak your application domain. That "unique id" you mention is exactly the use case for the idempotency key this RFC proposes. You can model your unique basket identifier in your application domain, and use that identifier as the idempotency key in interactions with third parties. This is useful mostly because networks and applications are not necessarily reliable.

ec109685 5y ago

The semantics don’t quite work out. If you don’t know the ID of a transaction, for example, using PUT with a client derived key wouldn’t make sense given a subsequent GET would be made against the transaction ID, not the idempotency key.

hcarvalhoalves 5y ago
An alternative is for the client to request an ID, another is for the server to respond the PUT with a 307 Temporary Redirect to GET the resource, idempotency is transparent for the client.