31–40 of 141 posts
While we're at it, let's remove HTTP headers and request bodies, and just stuff everything into the URL. I've written tons of shitty webapps that do exactly that, so it logically follows that we should force everyone to do it.
Removing DELETE and PUT would be a terrible idea, every REST API would break.
I thought someone would say this and I'm afraid it's bullshit. You can just put the REST operations in the URL. This also has the advantage that you aren't artificially restricting yourself to CRUD operations. Some operations do not map to those, e.g. logging out (DELETE user? ... No... DELETE session? I guess?). I explained in more detail here: http://stackoverflow.com/questions/2191049/what-is-the-advan...
(And GET/POST/PUT/DELETE isn't CRUD.)
If anything, I'd rather have a HTML spec that allows forms to do the other resource oriented verbs.
This post is all about how the author thinks the other verbs are useless, and they are pretty much useless in the browser. However, HTTP is not just for browsers...
And thus spoke someone who has never built a REST API, never used curl -I, and probably hasn't used anything other than a web browser to access HTTP content.
Sure, for the most part, we're all kinda new to REST, and we're slowly learning to construct good REST architecture. Sure, there's some redundant weird shit like SPACEJUMP. But we should aim to improve education and encouragement of the use of verbs such as PUT and DELETE, rather than abandon best practice because "no-one's going to use it" or YAGNI, when we can clearly see in talk after expert talk that these are the practices that are being recommended and already put to good use.
Not to mention the plethora of proxies, web servers, and tools that already support these accepted, recognised, standards-defined techniques.
While we're at it, let's remove HTTP headers and request bodies, and just stuff everything into the URL. I've written tons of shitty webapps that do exactly that, so it logically follows that we should force everyone to do it.
I was thinking something more along the lines of proprietary extensions to HTML5. Isn't that what everyone's doing now?
If anything, I'd rather have a HTML spec that allows forms to do the other resource oriented verbs.
Yes! Why is support for PUT and DELETE not specified in HTML specs? Also, why hasn't a browser implementation gone ahead and added support for both of those verbs as an extension beyond the spec?
Likewise, it doesn't make much sense to send a request body with a DELETE, regardless of what it contains. Not forbidden, but not really useful either.
"Practically speaking there are only two HTTP verbs: read and write, GET and POST." And thus spoke someone who has never built a REST API, never used curl -I, and probably hasn't used anything other than a web browser to access HTTP content. Sure, for the most part, we're all kinda new to REST, and we're slowly learning to construct good REST architecture. Sure, there's some redundant weird shit like SPACEJUMP. But w…
Here are Brett's projects: http://www.onebigfluke.com/
Maybe you've heard of some of them? PubSubHubbub, Google App Engine, Camlistore, Google Consumer Surveys.
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/e…
"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.
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/e…
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.