6 ms·

not nearly as bad, but I've worked at a company that tried really hard to be as pure REST as possible, closely following the http semantics for everything... ex

by shados 8y ago

not nearly as bad, but I've worked at a company that tried really hard to be as pure REST as possible, closely following the http semantics for everything... except they used POST for idempotent actions and PUT for the non-idempotent ones. That was....confusing on my first week.

meddlepal 8y ago
How'd they manage the fuck that up so badly?
- shados 8y ago
  Was pretty funny when we argued it. I explained http verbs to them after being told it was "THE REST STANDARD (TM)", and when I linked to them the http verb definitions, the reply I got was "Oh, I guess they must have changed them since last year, huh?" I can't make this shit up if I tried.
philwelch 8y ago
Having non-idempotent API endpoints in the first place is a bad idea. It might be unavoidable, if that endpoint directly controls some non-idempotent real world action that can't be managed with transaction ID's or the like, but an API endpoint being non-idempotent means that if there is ever a poorly-timed moment of service or network unavailability and you don't receive a healthy response from that API call, you have to be prepared to either completely drop whatever you were trying to do in the first place or accept the risk that it'll happen twice. At the risk of making an overly broad and offensive comment: amateurs discuss standards and semantics, professionals discuss resiliency and requirements.
- shados 8y ago
  How would you do a endpoint that creates, for example, a new resource? Like, if I have a todo list and I want 2 todo items with the same text. My create todo endpoint will have to be non-idempotent. That's what the semantics of a POST is for.
  - philwelch 8y ago
    Generate a UUID on the client side and pass it as a parameter, and configure the server not to process the same UUID twice. Though if it’s just a todo app, it probably doesn’t matter. It matters slightly more when the resources you’re creating are things like “purchase orders” or “payments” or “shipments” or “hailing an Uber”.

by shados 8y ago

meddlepal 8y ago

How'd they manage the fuck that up so badly?

shados 8y ago
Was pretty funny when we argued it. I explained http verbs to them after being told it was "THE REST STANDARD (TM)", and when I linked to them the http verb definitions, the reply I got was "Oh, I guess they must have changed them since last year, huh?" I can't make this shit up if I tried.

philwelch 8y ago

Having non-idempotent API endpoints in the first place is a bad idea. It might be unavoidable, if that endpoint directly controls some non-idempotent real world action that can't be managed with transaction ID's or the like, but an API endpoint being non-idempotent means that if there is ever a poorly-timed moment of service or network unavailability and you don't receive a healthy response from that API call, you have to be prepared to either completely drop whatever you were trying to do in the first place or accept the risk that it'll happen twice. At the risk of making an overly broad and offensive comment: amateurs discuss standards and semantics, professionals discuss resiliency and requirements.

shados 8y ago
How would you do a endpoint that creates, for example, a new resource? Like, if I have a todo list and I want 2 todo items with the same text. My create todo endpoint will have to be non-idempotent. That's what the semantics of a POST is for.
- philwelch 8y ago
  Generate a UUID on the client side and pass it as a parameter, and configure the server not to process the same UUID twice. Though if it’s just a todo app, it probably doesn’t matter. It matters slightly more when the resources you’re creating are things like “purchase orders” or “payments” or “shipments” or “hailing an Uber”.