3 ms·
I've about had it reading discussion after discussion on the topic of REST between people who haven't read the damned paper. Here is my takeaway: There isn't
by collint 16y ago
I've about had it reading discussion after discussion on the topic of REST between people who haven't read the damned paper.
Here is my takeaway:
There isn't much to do with URLs in here. One URL, One resource (collection counts as a resource). Talk about URLs all you want, there can bee good resource identifiers and bad ones. But REST doesn't care as long as you don't break the golden rule.
REST is an RPC system. You call remote procedures, GET, PUT, DELETE etc. on remote resources. You are probably not smart enough to do better than what naturally emerged as HTTP. Behemoths and industries have tried. But HTTP won, and it will win again.
- AffableSpatula 16y agoSorry that's wrong; neither REST as a style or HTTP as an implementation are RPC. One of the key components of REST is Layering which is made possible because REST is distinct from RPC. This is covered in the dissertation: http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluatio... 6.5.2 HTTP is not RPC People often mistakenly refer to HTTP as a remote procedure call (RPC) [23] mechanism simply because it involves requests and responses. What distinguishes RPC from other forms of network-based application communication is the notion of invoking a procedure on the remote machine, wherein the protocol identifies the procedure and passes it a fixed set of parameters, and then waits for the answer to be supplied within a return message using the same interface. Remote method invocation (RMI) is similar, except that the procedure is identified as an {object, method} tuple rather than a service procedure. Brokered RMI adds name service indirection and a few other tricks, but the interface is basically the same. What distinguishes HTTP from RPC isn't the syntax. It isn't even the different characteristics gained from using a stream as a parameter, though that helps to explain why existing RPC mechanisms were not usable for the Web. What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries almost as well as by the machines that originate services. The result is an application that allows for layers of transformation and indirection that are independent of the information origin, which is very useful for an Internet-scale, multi-organization, anarchically scalable information system. RPC mechanisms, in contrast, are defined in terms of language APIs, not network-based applications.
- davidmathers 16y agoShorter RTF: The client might GET from a cache, so obviously GET isn't a procedure running on the remote server.
- AffableSpatula 16y agoYeah, caching is a type of layering
- collint 16y agoWell color me stupid. I suppose I'm going to have to be more careful about what I call RPC.
- hparra 16y agoYou managed to read it all? I printed his dissertation out once and fell asleep at the beginning. If this happened to anyone else you can read a somewhat abridged version in his ACM paper: http://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf http://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf On another note, I remember reading his "musings" and getting the impression that he was mean and arrogant. I met him last year and he seemed like a nice guy. I was still careful to call my serial device HTTP resource server "RESTish" out of fear that I probably violated some principle somewhere.
- deleted 16y ago[deleted]