5 ms·

I don't really understand the obsession with using HTTP methods. OP brings up a good point that using only GET/PUT/POST/DELETE to only represent CRUD is extreme

I don't really understand the obsession with using HTTP methods. OP brings up a good point that using only GET/PUT/POST/DELETE to only represent CRUD is extremely limiting, but suggests that using even more obscure HTTP methods would be less limiting? I would argue not only is it limiting, it is also obscure, what is it about "PUT" that implies update vs. create? If you look at the twitter API (https://dev.twitter.com/docs/api https://dev.twitter.com/docs/api) (commonly held up as exemplary REST) you will see exactly 2 methods, GET and POST. GET means no state change other than logging, POST implies state change. This makes so much more sense because then you can use ?command= and have any command you want and not have people confused about what it means.

Dashron 15y ago
Put is supposed to be Idempotent (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1...). calling "PUT a=b&c=d" three times should be identical to calling it once. So any time you let the system generate an ID for the resource you should use POST. PUT works in creation when you know the id beforehand. I have not worked with amazon s3 but I hear they handle this well. You PUT a file to a url containing the file name. The first PUT creates the file on their end, any future PUT updates that file.
- bct 15y ago
  What's often left out is the reason that that's a useful rule to have: if PUTs are always idempotent, then you can always safely repeat a PUT if you're not sure whether it succeeded or not. This makes it easier to build robust systems.
o1iver 15y ago
Actually these is quite a big difference. PUT specifies the resource to be update, whilst POST does not do so. This means that you must (according to RFC 2616) use POST if you want to create a new resource and PUT if you want to change an existing resource or create one that you know "how to name". This disctinction is sometimes necessary, or at least useful (ex: idempotence of PUT). I don't understand how any even half-competent developer would be unable to understand this difference and act accordingly.
- jethroalias97 15y ago
  What if you want to update a value, but you want to store the number of times it was updated to be returned in the JSON (not idempotent, but not an unreasonable thing to want)? Would you still use PUT? My point is not that the ascribed meaning of POST and PUT is bad, I think the concepts behind both these functions are great, but what if you want to make a different or more complicated function? It makes sense to me to invent your own rather than be limited to what HTTP gives you.
  - bct 15y ago
    You examine the situation and determine what makes the most sense. Do you want the client to repeat the request if it's not sure whether it succeeded or not? If so, use PUT; otherwise use POST. This isn't complicated stuff.
    - ceol 15y ago
      There's no need to be condescending.
  - scott_w 15y ago
    I suppose you could expose the counter as a separate resource. It depends how important that counter is. If it's somewhat incidental, you could use PUT. If it's key to your system, use POST for updating the counted resource, because it's not idempotent.
bct 15y ago
> commonly held up as exemplary REST Not by people who know what they're talking about. > This makes so much more sense because then you can use ?command= and have any command you want and not have people confused about what it means. That's textbook RPC. It's a pattern that works well for many things, but it's definitely not REST.
- sopooneo 15y ago
  Very sincerely, why is REST an idea worth pursuing?
  - jamesbritt 15y ago
    Have you read Roy Felding's REST dissertation?
    - virmundi 15y ago
      Yes, I have. To me there seems to be an abstraction leak. Specifically he's baked HTML into his entire thesis. The idea of interconnecting hypermedia together is great. It does how ever limit on to using spec'ed hypermedia like HTML. HTML is one of the only spec media that can link out of the box. One of his goals was that a document would be able to provide links to another document in a natural, intuitive way. It is ment to be so intuitive in fact that the interchange of the document doesn't need a schema or WSDL like system. HTML has this ability. JSON however doesn't. If one wants to nest links in JSON, one has to tell the client how those links will appear. On has to define the structure beyond merely syntaxical correctness. This is where REST falls down, IMHO. So I recommend pursuing pieces of REST. But a full HATEOS concept seems to meaningfully limit on to symantec HTML.
      - jamesbritt 15y ago
        If one wants to nest links in JSON, one has to tell the client how those links will appear. On has to define the structure beyond merely syntaxical correctness. This is where REST falls down, IMHO. Then use HTML. Or some other representation with known link semantics. I don't see how failures or shortcomings of JSON indicate a problem with REST. They are orthogonal; JSON has nothing to do with REST, it's just a serialization format some people like.
generalk 15y ago
Where is the Twitter API held up as "exemplary REST"? I've usually seen Twilio's API as being the de-facto REST API. Not perfect, but pretty close.
phillco 15y ago
What I like about using GET (and, to some extent, POST) is that it makes it trivial to test your API in a browser while developing it. Just paste in the URL and you get the raw response, fetch time analysis, and everything else the Chrome developer tools provide you. This shouldn't matter much, but it does.
- FuzzyDunlop 15y ago
  XHR Poster[0] sounds like an extension you'll enjoy. It provides a much more comprehensive testing interface. [0]http://goo.gl/UFSdZ http://goo.gl/UFSdZ (links to Chrome extension store)
  - symkat 15y ago
    I'd add that one of the best features of XHR Poster is that it uses your cookies and any authentication you've already performed in Chrome when sending the requests. I had to build an API that lived inside a system with entirely too many authentication/cookie checks and using curl was becoming too awkward for testing, this saved me a lot of time.
  - ajtaylor 15y ago
    Thank you so much for the pointer! I've installed it, and I imagine I'll be using it quite a bit in the coming weeks at $work.
phillco 15y ago
What I like about using GET (and, to some extent, POST) is that it makes it trivial to test your API in a browser while developing it. Just paste in the URL and you get the raw response, fetch time analysis, and everything else the Chrome developer tools provide you. This shouldn't matter much, but it does.
hackernews 15y ago
>I don't really understand the obsession with >using HTTP methods. If I could break it down to the simplest form: GET requests can be cached, any other method should be processed.

Dashron 15y ago

Put is supposed to be Idempotent (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1...). calling "PUT a=b&c=d" three times should be identical to calling it once. So any time you let the system generate an ID for the resource you should use POST. PUT works in creation when you know the id beforehand. I have not worked with amazon s3 but I hear they handle this well. You PUT a file to a url containing the file name. The first PUT creates the file on their end, any future PUT updates that file.

bct 15y ago
What's often left out is the reason that that's a useful rule to have: if PUTs are always idempotent, then you can always safely repeat a PUT if you're not sure whether it succeeded or not. This makes it easier to build robust systems.

o1iver 15y ago

Actually these is quite a big difference. PUT specifies the resource to be update, whilst POST does not do so. This means that you must (according to RFC 2616) use POST if you want to create a new resource and PUT if you want to change an existing resource or create one that you know "how to name". This disctinction is sometimes necessary, or at least useful (ex: idempotence of PUT). I don't understand how any even half-competent developer would be unable to understand this difference and act accordingly.

jethroalias97 15y ago
What if you want to update a value, but you want to store the number of times it was updated to be returned in the JSON (not idempotent, but not an unreasonable thing to want)? Would you still use PUT? My point is not that the ascribed meaning of POST and PUT is bad, I think the concepts behind both these functions are great, but what if you want to make a different or more complicated function? It makes sense to me to invent your own rather than be limited to what HTTP gives you.
- bct 15y ago
  You examine the situation and determine what makes the most sense. Do you want the client to repeat the request if it's not sure whether it succeeded or not? If so, use PUT; otherwise use POST. This isn't complicated stuff.
  - ceol 15y ago
    There's no need to be condescending.
- scott_w 15y ago
  I suppose you could expose the counter as a separate resource. It depends how important that counter is. If it's somewhat incidental, you could use PUT. If it's key to your system, use POST for updating the counted resource, because it's not idempotent.

bct 15y ago

> commonly held up as exemplary REST Not by people who know what they're talking about. > This makes so much more sense because then you can use ?command= and have any command you want and not have people confused about what it means. That's textbook RPC. It's a pattern that works well for many things, but it's definitely not REST.

sopooneo 15y ago
Very sincerely, why is REST an idea worth pursuing?
- jamesbritt 15y ago
  Have you read Roy Felding's REST dissertation?
  - virmundi 15y ago
    Yes, I have. To me there seems to be an abstraction leak. Specifically he's baked HTML into his entire thesis. The idea of interconnecting hypermedia together is great. It does how ever limit on to using spec'ed hypermedia like HTML. HTML is one of the only spec media that can link out of the box. One of his goals was that a document would be able to provide links to another document in a natural, intuitive way. It is ment to be so intuitive in fact that the interchange of the document doesn't need a schema or WSDL like system. HTML has this ability. JSON however doesn't. If one wants to nest links in JSON, one has to tell the client how those links will appear. On has to define the structure beyond merely syntaxical correctness. This is where REST falls down, IMHO. So I recommend pursuing pieces of REST. But a full HATEOS concept seems to meaningfully limit on to symantec HTML.
    - jamesbritt 15y ago
      If one wants to nest links in JSON, one has to tell the client how those links will appear. On has to define the structure beyond merely syntaxical correctness. This is where REST falls down, IMHO. Then use HTML. Or some other representation with known link semantics. I don't see how failures or shortcomings of JSON indicate a problem with REST. They are orthogonal; JSON has nothing to do with REST, it's just a serialization format some people like.

generalk 15y ago

Where is the Twitter API held up as "exemplary REST"? I've usually seen Twilio's API as being the de-facto REST API. Not perfect, but pretty close.

phillco 15y ago

What I like about using GET (and, to some extent, POST) is that it makes it trivial to test your API in a browser while developing it. Just paste in the URL and you get the raw response, fetch time analysis, and everything else the Chrome developer tools provide you. This shouldn't matter much, but it does.

FuzzyDunlop 15y ago
XHR Poster[0] sounds like an extension you'll enjoy. It provides a much more comprehensive testing interface. [0]http://goo.gl/UFSdZ http://goo.gl/UFSdZ (links to Chrome extension store)
- symkat 15y ago
  I'd add that one of the best features of XHR Poster is that it uses your cookies and any authentication you've already performed in Chrome when sending the requests. I had to build an API that lived inside a system with entirely too many authentication/cookie checks and using curl was becoming too awkward for testing, this saved me a lot of time.
- ajtaylor 15y ago
  Thank you so much for the pointer! I've installed it, and I imagine I'll be using it quite a bit in the coming weeks at $work.

phillco 15y ago

hackernews 15y ago

>I don't really understand the obsession with >using HTTP methods. If I could break it down to the simplest form: GET requests can be cached, any other method should be processed.