Apparently, REST is just a set of conventions about how to use HTTP. I wonder which advantage these conventions provide. Does anyone know?
+8
A:
Simply put, REST means using HTTP the way it's meant to be.
Have a look at Roy Fielding's dissertation about REST. I think that every person that is doing web development should read it.
As a note, Roy Fielding is one of the key drivers behind the HTTP protocol, as well.
To name some of the advandages:
- Simple.
- You can make good use of HTTP cache and proxy server to help you handle high load.
- It helps you organize even a very complex application into simple resources.
- It makes it easy for new clients to use your application, even if you haven't designed it specifically for them (probably, because they weren't around when you created your app).
Emil Ivanov
2010-02-03 09:57:00
"Simple": Why is REST simpler than HTTP?
Dimitri C.
2010-02-03 10:33:55
"helps you organize": So this organization is more difficult when merely using GET and POST?
Dimitri C.
2010-02-03 10:37:24
"It makes it easy for new clients to use your application": this is about REST vs. plain HTTP, right?
Dimitri C.
2010-02-03 10:39:05
Conforming to REST constraints is definitely not simple. Squeezing complex business operations into four standard verbs is actually really hard sometimes. However, when done well, the end result can be simple to comprehend, but getting there is anything but.
Darrel Miller
2010-02-03 13:35:15
Dimitri, some search engines ignore dynamic links. Not so much any more, but it's still frowned upon. If you run a small site, then googlebot might not index all your pages if they have a question mark in the path.
wisty
2010-02-03 12:08:35
@wisty: ...which is just plainly false, when you mention Google: http://googlewebmastercentral.blogspot.com/2008/09/dynamic-urls-vs-static-urls.html
Boldewyn
2010-02-03 12:35:36
+5
A:
I recommend taking a look at Ryan Tomayko's How I Explained REST to My Wife
marcgg
2010-02-03 10:07:55
This is a nice text, but it didn't give any examples of why it would be bad to use GET and POST for everything.
Dimitri C.
2010-02-03 10:32:51
You can use GET and POST and still not violate any REST constraints. You don't need to use DELETE. e.g. Can you guess what the following request does `POST /Trashcan?url=/document/247` I am not violating any REST constraint by doing this. The uniform interface constraint says that when you use a verb it must do what the spec says it does. It does not imply that it is required to use all of the verbs, or even that if there is a more appropriate verb that you must use it.
Darrel Miller
2010-02-03 19:25:18
+2
A:
IMHO the biggest advantage that REST enables is that of reducing client/server coupling. It is much easier to evolve a REST interface over time without breaking existing clients.
Darrel Miller
2010-02-03 12:31:47
+1
A:
Caching.
There are other more in depth benefits of REST which revolve around evolve-ability via loose coupling and hypertext, but caching mechanisms are the main reason you should care about RESTful HTTP.
Mike
2010-02-03 16:23:04
Can you give an example what might be cached and why the caching wouldn't happen with a non-REST solution?
Dimitri C.
2010-02-03 16:38:39
@Dimitri C.: A link http://www.wikipedia.org/article?id=19 wouldnt be cached by a proxy, since it ignore parameters passed in the url. In the other hand a link http://www.wikipedia.org/REST would be cached, understood?
VP
2010-02-03 16:41:10
If caching was the main benefit of REST, I can assure you that I would not have spent the last two years building RESTful services.
Darrel Miller
2010-02-03 19:19:37
Darrel, you might be building systems that are at a scale of distribution in which loose coupling is of the highest importance (interested to know what type of systems these are), but most people aren't - or they're using technologies (i.e. browsers and html) in which a large majority of the hard work is done for them.
Mike
2010-02-03 19:37:34
+1
A:
- Give every “resource” an ID
- Link things together
- Use standard methods
- Resources with multiple representations
- Communicate statelessly
It is possible to do everything just with POST and GET? Yes, is it the best approach? No, why? because we have standards methods. If you think again, it would be possible to do everything using just GET.. so why should we even bother do use POST? Because of the standards!
For example, today thinking about a MVC model, you can limit your application to respond just to specific kinds of verbs like POST, GET, PUT and DELETE. Even if under the hood everything is emulated to POST and GET, don't make sense to have different verbs for different actions?
VP
2010-02-03 16:39:19
"it would be possible to do everything using just GET": I already did some experiments with HTTP GET in Silverlight. My conclusion was that GET messages are considerably limited in size, whereas POST messages can be bigger (again: in the Silverlight setting). Therefore I'd choose to use HTTP POST for everything! :-)
Dimitri C.
2010-02-04 08:06:05
both solutions are against the standards. Do everything via POST isn't good, specially for queries. Note that in the last years all search engines that used to work as GET works now as GET. Why? because the “get” method has this ability to get spidered...
VP
2010-02-04 11:52:31