I don't understand the point of "uri":"/transactions/1". Isn't the new resource's URI already part of the response (in the Location: header)? It's sort of like saying GET /posts/show/1 vs. GET /posts/1.
Nobody Understands REST or HTTP
31–40 of 141 posts
Re: Nobody Understands REST or HTTP
#32This is an excellent example of a spec being deemed more important than a useable system.
Frankly, I don't give a damn about the REST spec, and neither should you. When I see an API I want it to be simple and clear.
/getAllPages/
Hey, it's a verb and I've got a pretty good idea of what I'm going to get back
/getAllPageNames/returnType/JSON
Now I really know what I'm getting. The simplicity and usability of this structure absolutely trumps a spec compliant call that involves request headers and nouns.
If you're building a system that requires having read someones dissertation, you're not doing us any favors. Especially when it comes to an API. Keep it simple, stupid.
Remember that your understanding of what a URL 'is' or 'should be' comes from a great deal of technical experience. If you're not working day in and day out to make powerful tools accessible to people WITHOUT such experience, please stop programming. Really, get out of the pool. Whatever awesome knowledge you need to make a system work internally is invaluable, but your interfaces should make the world a simpler, more magical place.
Re: Nobody Understands REST or HTTP
#33He's right, but older web developers might remember the alternative, which was having no design pattern at all.
Most web developers aren't going to read the computer science papers about REST, and how strictly you want to adhere to it, depends on you, and your development team. It's a design pattern, or a tool, but it's not a religion.
On that note, I've gone into several job interviews where they ask me to explain what REST is, and I always start with, "REST stands for Representational State Transfer...", at which point, I get the feeling that the interviewer wasn't aware of that, and I wind up telling them way more about REST than I think they wanted to know.
Re: Nobody Understands REST or HTTP
#34This is a great article. One challenge I am facing now is both building a RESTful API, along with a UI that uses the API. The biggest question I have is the use of shebangs in urls with the ajaxy app. We must support IE so pushState is out, but shebang just seems like a hack. I think at this point I have no choice but to implement shebang but I wonder if there are any viable alternatives?
Re: Nobody Understands REST or HTTP
#35I had a really interesting conversation about this with a coworker a few weeks ago. We were talking about URL design. I argued for URLs like this: /networks/ /networks/girl_talk/ /networks/girl_talk/tracks/ /search?term=bass&sort=artist He argued for URLs like this (note the pluralization): /networks/ /network/girl_talk/ /network/girl_talk/tracks/ /search/bass/sort/artist/ My case boiled down to, “A URL represents th…
Either way I don't think it matters. Just get it done. Clients do not care about URL structure, they just want their problem solved. I redid an app and prettified the urls (yes I know this is slightly off topic) and no one has commented on it. Developers will use either, just do it and provide documentation and be done with it
This is the same position Mark Nottingham (http://www.mnot.net/personal/) takes and expresses in his talk "Leveraging the Web for Services at Yahoo!"(http://www.infoq.com/presentations/services-without-soap-yah...).
However, Mark created a service called "Is It RESTful?" (http://isitrestful.com/) to deal with all the engineers asking him that question :)
Re: Nobody Understands REST or HTTP
#36Very good read, and thorough. I particularly like the transaction example. It seems like a common idiom that trips people up with REST. However, I do have a problem with REST that I've been dealing with lately. Specifically, the question of web-hooks. Many services today allow you to pass a URL that they will hit with a POST request whenever something happens. A good example is the GitHub post-receive hook ( http://h…
What I've seen in the past (mainly from Pylons) is to have an extension on the end of the URL so: /updates/ has a default format say XML and then there's a JSON resource called /updates.json, /updates.txt, etc.
Keep in mind what the R in REST stands for. Each resource is a representation of internal data. You can have multiple representations under different URLs even though they're powered by the same internal data structure. Ideally you'd use the Accept header to do it but sometimes you need to be practical.
Re: Nobody Understands REST or HTTP
#37[deleted]
Re: Nobody Understands REST or HTTP
#38This is an excellent example of a spec being deemed more important than a useable system. Frankly, I don't give a damn about the REST spec, and neither should you. When I see an API I want it to be simple and clear. /getAllPages/ Hey, it's a verb and I've got a pretty good idea of what I'm going to get back /getAllPageNames/returnType/JSON Now I really know what I'm getting. The simplicity and usability of this struc…
Did you read the article? No matter nouns or verbs but in your example you are doing an HTTP GET. Does get getallpages sound right to you?
I did not downvote you but the REST architecture is well thought out, simple to follow, and very sufficient if you are moving content over HTTP.
Re: Nobody Understands REST or HTTP
#39I had a really interesting conversation about this with a coworker a few weeks ago. We were talking about URL design. I argued for URLs like this: /networks/ /networks/girl_talk/ /networks/girl_talk/tracks/ /search?term=bass&sort=artist He argued for URLs like this (note the pluralization): /networks/ /network/girl_talk/ /network/girl_talk/tracks/ /search/bass/sort/artist/ My case boiled down to, “A URL represents th…
Either way I don't think it matters. Just get it done. Clients do not care about URL structure, they just want their problem solved. I redid an app and prettified the urls (yes I know this is slightly off topic) and no one has commented on it. Developers will use either, just do it and provide documentation and be done with it
Exactly. REST is interesting, but understand why its interesting. If you're doing it because its a popular buzzword, that's just cargo cult.
It's good to know about REST so you can use it where it makes sense. But at the end of the day, doing what is right for your app trumps following any given methodology.
Re: Nobody Understands REST or HTTP
#40The title seems rather sensational. Is that really necessary?