4 ms·

You can really implement anything under any verb... Given the flexibility of http as a standard. I have always hoped to some day stumble across some madlad who

You can really implement anything under any verb... Given the flexibility of http as a standard. I have always hoped to some day stumble across some madlad who scales a large production system on the back of DELETE Although sadly browsers are starting to enforce the behaviors of verbs more and more... Someone hurry up and get coding

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”.
munk-a 8y ago
It isn't prevented but... it's like developing in an esoteric language, if your language interpreted any inequality as a test if the left hand value is lesser than the right hand value (i.e. 2 < 3 equivalent to 2 > 3, both are true) you _can_ work within it, but why bother. Use the common language constructs and design paradigms other people do unless you enjoy making it hellishly difficult to train up new people.
- batoure 8y ago
  So browsers have started to do a lot of rewrite on the periferal verbs. Grab XMLHttpRequest and start returning different content types in the header and body. Depending what browser you are in you will start to see things go inconsistently sideways compared to the same actions on get or post

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”.

munk-a 8y ago

It isn't prevented but... it's like developing in an esoteric language, if your language interpreted any inequality as a test if the left hand value is lesser than the right hand value (i.e. 2 < 3 equivalent to 2 > 3, both are true) you _can_ work within it, but why bother. Use the common language constructs and design paradigms other people do unless you enjoy making it hellishly difficult to train up new people.

batoure 8y ago
So browsers have started to do a lot of rewrite on the periferal verbs. Grab XMLHttpRequest and start returning different content types in the header and body. Depending what browser you are in you will start to see things go inconsistently sideways compared to the same actions on get or post