Nobody Understands REST or HTTP
blog.steveklabnik.com
Nobody Understands REST or HTTP
1–10 of 72 posts
Re: Nobody Understands REST or HTTP
#2This says versioning in the URI is wrong. Why? I much prefer separating my API versions into different files at the dispatcher level. Doing it with the header would be a mess in most frameworks, and I don't see what it hurts.
Also, what about custom HTTP verbs? Many times I need something more than GET/PUT/POST/DELETE. What happens then? I haven't seen anyone talk about that.
Re: Nobody Understands REST or HTTP
#3This says versioning in the URI is wrong. Why? I much prefer separating my API versions into different files at the dispatcher level. Doing it with the header would be a mess in most frameworks, and I don't see what it hurts. Also, what about custom HTTP verbs? Many times I need something more than GET/PUT/POST/DELETE. What happens then? I haven't seen anyone talk about that.
What I've come to realise is that if you try to make an API of any sort, somebody, somewhere, will write a post about how you're defiling the HTTP protocol.
Re: Nobody Understands REST or HTTP
#4This says versioning in the URI is wrong. Why? I much prefer separating my API versions into different files at the dispatcher level. Doing it with the header would be a mess in most frameworks, and I don't see what it hurts. Also, what about custom HTTP verbs? Many times I need something more than GET/PUT/POST/DELETE. What happens then? I haven't seen anyone talk about that.
What I've come to realise is that if you try to make an API of any sort, somebody, somewhere, will write a post about how you're defiling the HTTP protocol.
Totally true. For example, this author would have problem's with reddit's API, where you indicate that you are requesting JSON by adding .json to any URL. And you know what? The world doesn't come crashing down.
Re: Nobody Understands REST or HTTP
#5The part about "accept-language" doesn't address the real problem. If I copy the url to a piece of content that is available in 2 languages and send it to someone else, I want them to read it in the same language as I originally read it. Sadly, I cannot copy Accept-Headers in a fashion that "normal" people understand. To me, resources written in 2 different languages may be instances of the same thing, but not the same resource.
At worst, the page in question uses automatic translation (not so uncommon when it comes to large knowledge bases), so the translation might be odd.
Basically, according to the article, Wikipedia has it all wrong.
Re: Nobody Understands REST or HTTP
#6This says versioning in the URI is wrong. Why? I much prefer separating my API versions into different files at the dispatcher level. Doing it with the header would be a mess in most frameworks, and I don't see what it hurts. Also, what about custom HTTP verbs? Many times I need something more than GET/PUT/POST/DELETE. What happens then? I haven't seen anyone talk about that.
With a RESTful API you don't tend to need IDs most of the time, you just use URLs. So having all the versioning info in the URL is not so great, you change the version and suddenly all the URLs aren't valid anymore.
But more important that is upgrading a version on an API may not be an all or nothing thing. You might want to start using the new features of the API on one resource type but you aren't ready to upgrade your usage on everything else. If the version is in the API you'll have to take apart and put back together urls to get the right ones, this is logic you don't want to have to encode into your client. If on the other hand you use Accept headers to do versioning you can have as fine grained control as you need.
Regarding the custom HTTP verbs it may seem like you need those at first but in practice you really don't and there is almost always a good clean way of doing things that doesn't break anything (or so I've found). I find that the solution is usually to introduce another resource or two, the transactions example from the article is a perfect example of this.
I know it sometimes seems like this is all abstract stuff that has no impact on the real world but it does make sense eventually! It's really lovely to use a properly RESTful API :)
Re: Nobody Understands REST or HTTP
#7The part about "accept-language" doesn't address the real problem. If I copy the url to a piece of content that is available in 2 languages and send it to someone else, I want them to read it in the same language as I originally read it. Sadly, I cannot copy Accept-Headers in a fashion that "normal" people understand. To me, resources written in 2 different languages may be instances of the same thing, but not the sa…
I think different approaches are suitable for different situations. Quite often I think different translations of the same thing should be treated as different (but related) resources.
Re: Nobody Understands REST or HTTP
#8Earlier quoted context omitted.
What I've come to realise is that if you try to make an API of any sort, somebody, somewhere, will write a post about how you're defiling the HTTP protocol.
Totally true. For example, this author would have problem's with reddit's API, where you indicate that you are requesting JSON by adding .json to any URL. And you know what? The world doesn't come crashing down.
There's nothing wrong with doing that. A resource can have multiple URLs and multiple representations. That's fine, in the right circumstances.
Re: Nobody Understands REST or HTTP
#9Interesting. But it has one flaw; how exactly would I do this
curl https://api.twilio.com/2010-04-01/Accounts -H "Accept: application/json
inside a browser on a normal GET request?
Re: Nobody Understands REST or HTTP
#10The part about "accept-language" doesn't address the real problem. If I copy the url to a piece of content that is available in 2 languages and send it to someone else, I want them to read it in the same language as I originally read it. Sadly, I cannot copy Accept-Headers in a fashion that "normal" people understand. To me, resources written in 2 different languages may be instances of the same thing, but not the sa…
I think different approaches are suitable for different situations. Quite often I think different translations of the same thing should be treated as different (but related) resources.
Sure, but the article makes it look like language encoded in the url is all wrong, while I think that (most of the time) it is exactly what you want. ACCEPT_LANGUAGE is a perfect for educated guessing of a users preferred language, but not for referencing an article.