12 ms·

I'm not sure what upset this Mr. Graffittis so much, but he seems to be excessively angry with HTTP verbs . Anyway, thousands of developers have found ways arou

I'm not sure what upset this Mr. Graffittis so much, but he seems to be excessively angry with HTTP verbs . Anyway, thousands of developers have found ways around this problem. Here is one: Most people use GET for retrieval, POST to change system state and DELETE to delete an object. You might go crazy and experiment with PUT, or not, your choice. As a team, you can establish some easy rules too (e.g. is it books/1 or books/book/1 to query a single book?). Sure, REST is not going to answer every problem, but no standard ever does. Standards are meant as guidelines (esp. those related to naming conventions like REST). Have fun with it. Stop the hate.

batoure 8y ago
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
philwelch 8y ago
(disclaimer: TFA is dead for me right now so I might be speaking out of context) REST (like "object-oriented programming") is an ambiguous term that might refer to a reasonable and usable subset of behavior, or it might refer to a more extensive hypermedia-style design pattern. REST, in the hypermedia sense, and in the sense of "the design principles behind HTTP in the first place", is a good way for a server to expose data to an intelligent human-guided client (i.e. a web browser). It doesn't do a lot for the API case, but it does a little and there's enough tooling to get you the rest of the way. I usually don't even think of REST API's as RESTful. I think of them as RPCs that exchange JSON, except you define the RPC endpoint as an HTTP verb/URL pattern tuple, accept and treat as a contract the standards behind different verbs, use response codes for out-of-band metadata, and piggyback on all the tooling and infrastructure that people already built around serving HTTP to web browsers in the first place. If you want to strongly type your RPC, you can use OpenAPI. If you want to define your RPC ahead of time and then generate server and/or client code from a definition, you can use Swagger Codegen. There's enough adequate tooling that you don't necessarily need to resort to an actual RPC protocol, but that doesn't mean your REST API actually has to be RESTful in any meaningful way, or even that it should be.
- weberc2 8y ago
  > is a good way for a server to expose data to an intelligent human-guided client (i.e. a web browser) A web-browser doesn't have any concept of REST; it only provides a sandbox for the client code which knows how to map paths to data (but pretty much never does so by means of any sort of introspection). Note that this isn't advocating against REST or in favor of RPC, just a neutral observation.
  - deleted 8y ago
    [deleted]
  - munk-a 8y ago
    Actually the original, core, really REST thing (that almost no one views as REST anymore) is all about resource exposure, and a dumb browser doesn't know how to interact with it but a REST aware generic browser could potentially interact with RESTful endpoints without other assistance. I'm specifically talking about the portion of rest that includes delivering actions with noun results, i.e. "Here's you comment record, if you want to edit it go to this URL, if you want to delete it here's a different one". Also, I, personally, find that portion of REST to be silly. I like the organizational hints and guidelines, but the resource discovery seems far too pipe-dreamy to ever be built on a large scale.
nkkollaw 8y ago
What about PATCH? I personally like PUT even for delta updates, but a dev I was working with was obsessed with wanting PATCH.
- jgalentine007 8y ago
  I like put for updates and patch for partial updates (but without the command/diff structure - only fields that are provided are patches)
- geezerjay 8y ago
  Your colleague was right: put is for total object replacement and patch is for partial object update. The guiding principle is: * POST: create new object, including their primary keys. Run appropriate sanity checks. * PUT: extract old entity object and update all attributes and dependencies, possibly deleting and regenerating all dependencies while preserving the object's keys. * PATCH: extract old entity object and update a small subset of its attributes. Run sanity checks that are specific to this form of update, and avoid touching bits in the persistence layer that are not linked with the update. Put is very important because total entity replacements really don't replace the role of partial updates, particularly if we consider how extensive transactions can become.
  - nkkollaw 8y ago
    Yes, I know he's right technically, but I've never seen it in any popular APIs. Unless, of course, I am mistaken.
    - geezerjay 8y ago
      Yes you do have a point. Even the OData standard specifies that PUT is the catch-all verb for entity updates, although there is a hefty discussion on introducing PATCH.
      - nkkollaw 8y ago
        We've been implementing PATCH operation using PUT. If a certain properties in not undefined, we update it, otherwise we don't.
rhacker 8y ago
Personally I think GraphQL's existence, while seemingly blatantly obvious in retrospect, is was what REST should have been. It lets "generic" applications to discover the API and its associated operations. Essentially its also simply a re-do of what Swagger (and a few others) attempted to do, but never really made REST work (imho). Here's a good analogy: Graphql is docker, REST is LXC.
- chewbacha 8y ago
  Might be more accurate to say that SOAP is LXC and GraphQL is docker.
- romeisendcoming 8y ago
  So one is user configurable and understandable (leaves much to the user) and the other is a black box that performs magic? One takes some time to understand and make work while the other just does the right thing 85% of the time?
danellis 8y ago
> As a team, you can establish some easy rules too (e.g. is it books/1 or books/book/1 to query a single book?). That's the thing about REST; you don't need any rules about what paths look like, because you shouldn't be constructing them manually. You get them from the State that was Transferred to you.
coldtea 8y ago
>I'm not sure what upset this Mr. Graffittis so much, but he seems to be excessively angry with HTTP verbs One thing that upsets me is pop psychology and second guessing of emotions (about "being upset", "excessively angry", etc) instead of arguments. >Have fun with it. Engineering is not about having arbitrary fun with whatever "standard" we are given.

batoure 8y ago

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

philwelch 8y ago

(disclaimer: TFA is dead for me right now so I might be speaking out of context) REST (like "object-oriented programming") is an ambiguous term that might refer to a reasonable and usable subset of behavior, or it might refer to a more extensive hypermedia-style design pattern. REST, in the hypermedia sense, and in the sense of "the design principles behind HTTP in the first place", is a good way for a server to expose data to an intelligent human-guided client (i.e. a web browser). It doesn't do a lot for the API case, but it does a little and there's enough tooling to get you the rest of the way. I usually don't even think of REST API's as RESTful. I think of them as RPCs that exchange JSON, except you define the RPC endpoint as an HTTP verb/URL pattern tuple, accept and treat as a contract the standards behind different verbs, use response codes for out-of-band metadata, and piggyback on all the tooling and infrastructure that people already built around serving HTTP to web browsers in the first place. If you want to strongly type your RPC, you can use OpenAPI. If you want to define your RPC ahead of time and then generate server and/or client code from a definition, you can use Swagger Codegen. There's enough adequate tooling that you don't necessarily need to resort to an actual RPC protocol, but that doesn't mean your REST API actually has to be RESTful in any meaningful way, or even that it should be.

weberc2 8y ago
> is a good way for a server to expose data to an intelligent human-guided client (i.e. a web browser) A web-browser doesn't have any concept of REST; it only provides a sandbox for the client code which knows how to map paths to data (but pretty much never does so by means of any sort of introspection). Note that this isn't advocating against REST or in favor of RPC, just a neutral observation.
- deleted 8y ago
  [deleted]
- munk-a 8y ago
  Actually the original, core, really REST thing (that almost no one views as REST anymore) is all about resource exposure, and a dumb browser doesn't know how to interact with it but a REST aware generic browser could potentially interact with RESTful endpoints without other assistance. I'm specifically talking about the portion of rest that includes delivering actions with noun results, i.e. "Here's you comment record, if you want to edit it go to this URL, if you want to delete it here's a different one". Also, I, personally, find that portion of REST to be silly. I like the organizational hints and guidelines, but the resource discovery seems far too pipe-dreamy to ever be built on a large scale.

nkkollaw 8y ago

What about PATCH? I personally like PUT even for delta updates, but a dev I was working with was obsessed with wanting PATCH.

jgalentine007 8y ago
I like put for updates and patch for partial updates (but without the command/diff structure - only fields that are provided are patches)
geezerjay 8y ago
Your colleague was right: put is for total object replacement and patch is for partial object update. The guiding principle is: * POST: create new object, including their primary keys. Run appropriate sanity checks. * PUT: extract old entity object and update all attributes and dependencies, possibly deleting and regenerating all dependencies while preserving the object's keys. * PATCH: extract old entity object and update a small subset of its attributes. Run sanity checks that are specific to this form of update, and avoid touching bits in the persistence layer that are not linked with the update. Put is very important because total entity replacements really don't replace the role of partial updates, particularly if we consider how extensive transactions can become.
- nkkollaw 8y ago
  Yes, I know he's right technically, but I've never seen it in any popular APIs. Unless, of course, I am mistaken.
  - geezerjay 8y ago
    Yes you do have a point. Even the OData standard specifies that PUT is the catch-all verb for entity updates, although there is a hefty discussion on introducing PATCH.
    - nkkollaw 8y ago
      We've been implementing PATCH operation using PUT. If a certain properties in not undefined, we update it, otherwise we don't.

rhacker 8y ago

Personally I think GraphQL's existence, while seemingly blatantly obvious in retrospect, is was what REST should have been. It lets "generic" applications to discover the API and its associated operations. Essentially its also simply a re-do of what Swagger (and a few others) attempted to do, but never really made REST work (imho). Here's a good analogy: Graphql is docker, REST is LXC.

chewbacha 8y ago
Might be more accurate to say that SOAP is LXC and GraphQL is docker.
romeisendcoming 8y ago
So one is user configurable and understandable (leaves much to the user) and the other is a black box that performs magic? One takes some time to understand and make work while the other just does the right thing 85% of the time?

danellis 8y ago

> As a team, you can establish some easy rules too (e.g. is it books/1 or books/book/1 to query a single book?). That's the thing about REST; you don't need any rules about what paths look like, because you shouldn't be constructing them manually. You get them from the State that was Transferred to you.

coldtea 8y ago

>I'm not sure what upset this Mr. Graffittis so much, but he seems to be excessively angry with HTTP verbs One thing that upsets me is pop psychology and second guessing of emotions (about "being upset", "excessively angry", etc) instead of arguments. >Have fun with it. Engineering is not about having arbitrary fun with whatever "standard" we are given.