5 ms·
The REST version makes it clear that you are dealing with operations on a resource. The URL identifies a thing in a consistent way, while the method and corresp
by enjo 14y ago
The REST version makes it clear that you are dealing with operations on a resource. The URL identifies a thing in a consistent way, while the method and corresponding data allow you to manipulate it.
The biggest benefit comes when building a cache architecture. RESTful API's (when properly implemented) come with built-in assumptions about idempotency. You end up in a place where you can easily cache GET requests while reasoning in a very consistent way about where changes to a resource will be made.
It's a pattern that comes with a lot of really useful benefits.
Now all of those same qualities can be built into other architectural styles (such as the one you propose). However, I find that it becomes much harder to reason about the role of operations and what they're actually doing when you lose that clear distinction that REST enforces.
I do want to quibble with one thing as well:
In REST the parameters are spread over 3 places, the action, the url and the post parameters themselves
That's true for any modular system isn't it? You have the object you are operating on, you have the operation, and you have the data. Object-oriented systems and even most structured languages (like Javascript for instance) make this distinction at some level. Why is that not appropriate for web architecture?
- pixie_ 14y agoJust because something is GET doesn't mean it can be cached. It's not consistent, and every API call needs to be evaluated individually. The thing with REST is that it treats all functions as a variant of a CRUD operation, while functions may do more than just CRUD or a combination of CRUD operations in a single API call. Imagine if all your javascript functions had to be prefixed with GET/UPDATE/DELETE/etc.. you would feel constricted, and for what reason? Imagine if your function names had data in the call path MyCourse.32423.Delete(); that doesn't look very good does it? 32423 would look alot better inside Delete().
- enjo 14y agoGET requests, by definition, should have no side-effects. Which makes them cacheable. Many browsers cache GET requests by default unless cache-control tells them not to. You can most definitely write a GET request that contains side-effects, but that's because you're doing it wrong (tm). Imagine if your function names had data in the call path MyCourse.32423.Delete(); that doesn't look very good does it? 32423 would look alot better inside Delete(). That's not data, that's an object. "MyCourse.32423" is the actual resource. It would actually look something more like: MyCourse32423.Delete(); Which seems pretty reasonable to me if we're trying to map this into programming language semantics (which I'm not even sure we should be doing).
- Domenic_S 14y agoI cringe a little bit whenever someone tries to present caching as simple or straightforward.
- drivebyacct2 14y agoI don't see that anywhere in the post. All I saw was "GET"s shouldn't modify state and should be cacheable. That seems perfectly in line with the spec.
- jebblue 14y agoThe only problem I have with your comment is that REST is not specified, it's a style: http://en.wikipedia.org/wiki/Representational_state_transfer http://en.wikipedia.org/wiki/Representational_state_transfer
- Ramone 14y agoGET being cacheable/idempotent is part of the HTTP spec, and has nothing to do with REST: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.9 http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13...
- drivebyacct2 14y agoI meant the HTTP spec which is where GETs specified.
- SilasX 14y ago>It's a pattern that comes with a lot of really useful benefits. Sure, but people can implement that pattern without buying into the whole clumsy REST edifice. For example, a strict reading of REST (and RESTers support such readings!) would tell me that if I have an API that takes two cities and returns the distance between them, then I must expose a URI pointing to every combination of cities. See here: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... >>A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) ... From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. ... [Failure here implies that out-of-band information is driving interaction instead of hypertext.] [emphasis mine] So, 1000 cities, you must send a million links over the network rather than 1000 possible parameters plus the formatting. Now, some RESTers assure me that, no, you can somehow communicate to the user that [prefix] / [first city] / [second city] will get you that answer; that a server can "instruct clients on how to construct appropriate URIs". Fine, but then we're right back to custom, author-documented APIs and RPCs: "to do that, format the call this way". Right back where we were before trying to force-fit everything into a CRUD mold with increasingly bizarre tables just to make all the calls work. Or maybe a REST purist would tell me that I'm supposed to link a URI for the starting city: [root]/distances/[start city]/, and then from there link them to possible choices of the second city: [root]/distances/[start city]/[end city]/ . Fine, but why jump through two pointless hoops, when I know what I want, and I prefer to just send one request rather than pointlessly spend bandwidth navigating a path I don't care for?