6 ms·

Arguing to replace a well-defined single idiom (verbs) with some arbitrary combination of URI, custom headers, request body contents is exactly the opposite of

by tl 13y ago

Arguing to replace a well-defined single idiom (verbs) with some arbitrary combination of URI, custom headers, request body contents is exactly the opposite of what you want. Using defined verbs instead of having each site do their own slightly different thing makes APIs easier to discover / consume. Also, I feel like "Execution in the Kingdom of Nouns" is semi-relevant here: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

generj 13y ago
"Execution in the Kingdom of Nouns" is excellent. Anyone who hasn't read it should do so immediately. I want some expansion of verbs, counterbalanced with the elimination of some of the less useful verbs. The focus should be towards forcing webbrowsers away from GET and POST. OPTIONS should be made mandatory.
- AlexanderDhoore 13y ago
  Hadn't read it. Did so immediately. Very good read! God I love it when people hate on java. (I know I shouldn't, but I do.)
  - guard-of-terra 13y ago
    He's not only bashing java but writes a lot of java. Are you as comfortable with that?
    - AlexanderDhoore 13y ago
      Sure why not. Makes his opinion even more valid. There is a LOT of truth in that essay.
    - YellowRex 13y ago
      I write tons of Java in my day job, and at this point it only hurts when I laugh.
- coffeeyesplease 13y ago
  Thank you soo much for "Execution in the Kingdom of Nouns". It 's been a while since I cried laughing. As someone who's been programming in java since 97 (..God I'm old) I certainly saw myself wandering around the Kingdom of Nouns
ianb 13y ago
> Arguing to replace a well-defined single idiom (verbs) with some arbitrary combination of URI, custom headers, request body contents is exactly the opposite of what you want. It may not be what you want, but it is what you'll get. It's what you'll get now, and in the future. There isn't much in the way of discoverable APIs that adhere to the data model suggestion in the HTTP spec, and that's becoming more true as time goes on. As HTTP APIs become more popular they have become less normalized. It's natural: if you want to expose something, you want to expose it as it is. Not many things adhere to the verb structure of HTTP, I'm not sure anything does unless it was designed to be HTTP from the ground up – which isn't how you should design an API, you should design it to do something useful from the ground up.
- lusr 13y ago
  > There isn't much in the way of discoverable APIs that adhere to the data model suggestion in the HTTP spec I don't even understand why this needs to be pointed out. If the precise usage of all web APIs could be inferred from the verb alone, presumably all web APIs are exactly the same. That's nonsensical. I challenge anybody to honestly claim they have consumed a 3rd party web API of material complexity without once referring to the documentation and solely relying on guessing HTTP verbs. Once you're already reading the API documentation, I don't understand why you'd prefer "http.request('PUT', '/resource')" over "http.post('/resource/put'). Even better, you can choose a URI that makes the most sense to your domain model, e.g. '/resource/upload'. I don't understand why you'd want to have less expressive URIs AND more work. In even this simple example, the verb is unlikely to be adequate in any case - if you need to supply options or metadata the verb is even less significant as to the true meaning of the operation. The fact is you can always embed the verb of your choice into the URI - thereby making a GET/POST/HEAD world no more or less expressive than a Verbtopia world. All that extra verbs do is cause consumers of the API to have to remember two pieces of information (VERB + URI) rather than one (URI). At least URIs can be constructed to make as much semantic sense as possible within a given domain model - VERBs, on the other hand, end up as square pegs in round holes, making them far less memorable.
  - dragonwriter 13y ago
metaphorm 13y ago
I think the argument was to remove just the unused verbs. I think GET, POST, and HEAD are the ones that make up 99.9% of all use on the web and those are the ones the author thinks should be the only verbs in HTTP.
- UnoriginalGuy 13y ago
  99.9% What? Has nobody on HK ever used REST either as a consumer or producer? http://en.wikipedia.org/wiki/Representational_state_transfer#Vocabulary_re-use_vs._its_arbitrary_extension:_HTTP_and_SOAP http://en.wikipedia.org/wiki/Representational_state_transfer...
  - jscheel 13y ago
    Problem is, in a lot of circumstances, you still have to rely on GET and POST with a header like X-REQUEST-METHOD set to tell the server what you really meant.
    - dragonwriter 13y ago
      Usually, this is not the server not supporting it, its a workaround that the server provides so that you can consume the API without AJAX from HTML forms, which are restricted to GET and POST. EDIT: Although in some cases there is an issue that people choose not to configure it on the web server, and instead use headers or other mechanisms to tunnel the "real" method to the application. But most servers do support it, this seems to be a mechanism for routing around administrative issues in organizations.
      - danabramov 13y ago
        “But most servers do support it, this seems to be a mechanism for routing around administrative issues in organizations.” Spot on.
  - metaphorm 13y ago
    sure we have. have you read through the developer docs for most API's? here's twitters: https://dev.twitter.com/docs/api/1.1 https://dev.twitter.com/docs/api/1.1 its all GET and POST. this is typical.

by tl 13y ago

generj 13y ago

"Execution in the Kingdom of Nouns" is excellent. Anyone who hasn't read it should do so immediately. I want some expansion of verbs, counterbalanced with the elimination of some of the less useful verbs. The focus should be towards forcing webbrowsers away from GET and POST. OPTIONS should be made mandatory.

AlexanderDhoore 13y ago
Hadn't read it. Did so immediately. Very good read! God I love it when people hate on java. (I know I shouldn't, but I do.)
- guard-of-terra 13y ago
  He's not only bashing java but writes a lot of java. Are you as comfortable with that?
  - AlexanderDhoore 13y ago
    Sure why not. Makes his opinion even more valid. There is a LOT of truth in that essay.
  - YellowRex 13y ago
    I write tons of Java in my day job, and at this point it only hurts when I laugh.
coffeeyesplease 13y ago
Thank you soo much for "Execution in the Kingdom of Nouns". It 's been a while since I cried laughing. As someone who's been programming in java since 97 (..God I'm old) I certainly saw myself wandering around the Kingdom of Nouns

ianb 13y ago

> Arguing to replace a well-defined single idiom (verbs) with some arbitrary combination of URI, custom headers, request body contents is exactly the opposite of what you want. It may not be what you want, but it is what you'll get. It's what you'll get now, and in the future. There isn't much in the way of discoverable APIs that adhere to the data model suggestion in the HTTP spec, and that's becoming more true as time goes on. As HTTP APIs become more popular they have become less normalized. It's natural: if you want to expose something, you want to expose it as it is. Not many things adhere to the verb structure of HTTP, I'm not sure anything does unless it was designed to be HTTP from the ground up – which isn't how you should design an API, you should design it to do something useful from the ground up.

lusr 13y ago
> There isn't much in the way of discoverable APIs that adhere to the data model suggestion in the HTTP spec I don't even understand why this needs to be pointed out. If the precise usage of all web APIs could be inferred from the verb alone, presumably all web APIs are exactly the same. That's nonsensical. I challenge anybody to honestly claim they have consumed a 3rd party web API of material complexity without once referring to the documentation and solely relying on guessing HTTP verbs. Once you're already reading the API documentation, I don't understand why you'd prefer "http.request('PUT', '/resource')" over "http.post('/resource/put'). Even better, you can choose a URI that makes the most sense to your domain model, e.g. '/resource/upload'. I don't understand why you'd want to have less expressive URIs AND more work. In even this simple example, the verb is unlikely to be adequate in any case - if you need to supply options or metadata the verb is even less significant as to the true meaning of the operation. The fact is you can always embed the verb of your choice into the URI - thereby making a GET/POST/HEAD world no more or less expressive than a Verbtopia world. All that extra verbs do is cause consumers of the API to have to remember two pieces of information (VERB + URI) rather than one (URI). At least URIs can be constructed to make as much semantic sense as possible within a given domain model - VERBs, on the other hand, end up as square pegs in round holes, making them far less memorable.
- dragonwriter 13y ago

metaphorm 13y ago

I think the argument was to remove just the unused verbs. I think GET, POST, and HEAD are the ones that make up 99.9% of all use on the web and those are the ones the author thinks should be the only verbs in HTTP.

UnoriginalGuy 13y ago
99.9% What? Has nobody on HK ever used REST either as a consumer or producer? http://en.wikipedia.org/wiki/Representational_state_transfer#Vocabulary_re-use_vs._its_arbitrary_extension:_HTTP_and_SOAP http://en.wikipedia.org/wiki/Representational_state_transfer...
- jscheel 13y ago
  Problem is, in a lot of circumstances, you still have to rely on GET and POST with a header like X-REQUEST-METHOD set to tell the server what you really meant.
  - dragonwriter 13y ago
    Usually, this is not the server not supporting it, its a workaround that the server provides so that you can consume the API without AJAX from HTML forms, which are restricted to GET and POST. EDIT: Although in some cases there is an issue that people choose not to configure it on the web server, and instead use headers or other mechanisms to tunnel the "real" method to the application. But most servers do support it, this seems to be a mechanism for routing around administrative issues in organizations.
    - danabramov 13y ago
      “But most servers do support it, this seems to be a mechanism for routing around administrative issues in organizations.” Spot on.
- metaphorm 13y ago
  sure we have. have you read through the developer docs for most API's? here's twitters: https://dev.twitter.com/docs/api/1.1 https://dev.twitter.com/docs/api/1.1 its all GET and POST. this is typical.