4 ms·

Can someone please explain to me how REST is anything but a pompous name for HTTP? Or how it has applicability to any kind of service other than document manage

Can someone please explain to me how REST is anything but a pompous name for HTTP? Or how it has applicability to any kind of service other than document management? All of the criteria stipulated in chapter 5 of the Fielding dissertation are spelled out in the RFCs that describe HTTP and related technologies, and _they only apply to documents_. There are other verbs that need to be applied over a network. I think the (sane) pro-REST argument can be summed up in the following: 'HTTP is a wonderful way to do CRUD operations over a network. Wouldn't it be cool if there was a catchy word to remind people that HTTP has a lot more to it than most people are aware of?'. This bollocks about REST being able to replace RPC is like having an argument about whether cars of airplanes are a better way to get around. And please stop torturing your service models to look like URLs just to be fashionable (I know, if I want upmod a comment I can POST to /comment/1234/karma/new! No, 'Upmod' is a distinct verb that doesn't have anything to do with GET or POST or PUT or HEAD or DELETE). If the thing you are modeling isn't a document in any sense, then don't try to model it as one. What I think people really mean when they say REST is 'ad-hoc RPC over HTTP using reasonably lightweight serialization', which is quite a lovely idea in its own right. The decision about using SOAP or a more lightweight RPC really boils down to the languages on each side of the wire. If the languages are structurally typed with object literal syntax then you want to use something lightweight, as the impedance mismatch between a literal Ruby datastructure and JSON is low. If you are connecting two nominally typed (often early bound) languages then you want SOAP, because if you're into that bondage and discipline thing then you need a WSDL to make sure that no one's boundaries get crossed. And pulling the result out of an HTTP response in Java is a lot easier with Axis than trying to parse some loosely specified JSON blob (unless you're coding in Perl, in which case I'll take the JSON blob any day). Don't debate SOAP/REST, if you must have some silly religious debate between two technology stacks which are both reasonable tools well suited to certain activities then at least debate Java/Python, the appropriate choice of RPC philosophy sort of falls out.

johnm 19y ago
Ouchy. Basically, it looks like you're taking a very narrow view of REST and conflating lots of it with historical RPC-ish thinking. Re: There are other verbs that need to be applied over a network. Please name one that's actually needed.
- benreesman 19y ago
  > Ouchy. Basically, it looks like you're taking a very narrow view of REST and conflating lots of it with historical RPC-ish thinking. My view of REST is narrow only in the sense that I've actually read the document where the term originated, which gives a rather precise (in places mathematically precise) definition of the term. If this level of rigor interests you then you can find this document at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch.... There only thing that is 'historical' about RPC is the thousands of real-world applications implemented in this style in every conceivable area of distributed computing over the last 3 or 4 decades. Whole programming languages both academic (Newsqueak) and industrial (Erlang) are premised on the notion of distributed message passing and you will be hard pressed to find any nontrivial distributed system that doesn't require the ability to invoke a verb over the network (including HTTP). From Fielding's dissertation: 'The primary distinction between network-based architectures and software architectures in general is that communication between components is restricted to message passing [6], or the equivalent of message passing if a more efficient mechanism can be selected at run-time based on the location of components [128].' HTTP itself is a form of RPC, with distinct named methods and a way of passing arguments and retrieving results. Hard-line REST advocates fall into one of four categories: 1) They believe that HTTP is a wonderful RPC protocol for doing CRUD on entities that can be roughly called 'documents', but would never dream of trying to torture some dramatically different domain into this model. When they are writing services that are document processing services they write them in a 'RESTful' style, and they otherwise never do. 2) They believe that all network transactions can be sensibly accomplished with a model that has only GET, PUT, POST, HEAD and DELETE, and that uses them as originally intended. 3) They believe that any software system that can't be accomplished as with (2) above isn't worth writing. (Web 2.0 with Rails anyone?) 4) They don't know what REST means. If #2 describes someone then he or she is inexperienced or stupid or both, if #3 describes someone then he or she is a fashion-conscious Web 2.0 asshole who will only ever receive money that came from a venture capitalist and never money that came from a customer. Ever. And if #4 describes someone then he or she really ought to read the literature before posting flippant drive-by commentary to Hacker News in what can only be some lame attempt at karma-whoring on the fashionability of the word 'REST'. > Please name one that's actually needed. Before replying to this I need to make it explicitly clear that I can only reply to what I think you're actually saying, so excuse (and correct) me if I reply to something that you didn't actually say. It sounds to me like you're proposing that GET, PUT, POST, HEAD, and DELETE are the only verbs that anyone should ever be interested in invoking over a network. Now there is a sense in which they might be sufficient for most transactions since you can attach an arbitrary payload to a POST and receive and arbitrary reply, but I think almost anyone would agree that this falls under the point made in my original post about the fact that people actually just want lightweight RPC when they talk about REST. For the sake of argument I'm happy to propose something that people might like to do with a web-service that doesn't fit a document CRUD model: play chess. Now while you may be able to GET a description of the current board with some resource identifier like /chess/game/1234/board, you will no doubt also want to MOVE and maybe even CONCEDE, and the moment that you've started POSTing to URLs that look like /chess/game/1234/move or /move/new you're right back to POSTing to a URL with another method name in it, i.e. lightweight RPC over HTTP and it's not REST anymore. The chess example is arguably contrived (and arguably not) but it doesn't take much imagination to start picturing web services for the remote compilation of code, or the provisioning of mobile devices, or calibration of remote underwater sensors. Just because a bunch of people have decided that social-networking is the most demanding application that we as developers should ever contemplate doesn't mean that the ability to do distributed message passing and procedure call is obsolete. Plenty of people are making plenty of money doing just that.

johnm 19y ago

Ouchy. Basically, it looks like you're taking a very narrow view of REST and conflating lots of it with historical RPC-ish thinking. Re: There are other verbs that need to be applied over a network. Please name one that's actually needed.

benreesman 19y ago
> Ouchy. Basically, it looks like you're taking a very narrow view of REST and conflating lots of it with historical RPC-ish thinking. My view of REST is narrow only in the sense that I've actually read the document where the term originated, which gives a rather precise (in places mathematically precise) definition of the term. If this level of rigor interests you then you can find this document at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch.... There only thing that is 'historical' about RPC is the thousands of real-world applications implemented in this style in every conceivable area of distributed computing over the last 3 or 4 decades. Whole programming languages both academic (Newsqueak) and industrial (Erlang) are premised on the notion of distributed message passing and you will be hard pressed to find any nontrivial distributed system that doesn't require the ability to invoke a verb over the network (including HTTP). From Fielding's dissertation: 'The primary distinction between network-based architectures and software architectures in general is that communication between components is restricted to message passing [6], or the equivalent of message passing if a more efficient mechanism can be selected at run-time based on the location of components [128].' HTTP itself is a form of RPC, with distinct named methods and a way of passing arguments and retrieving results. Hard-line REST advocates fall into one of four categories: 1) They believe that HTTP is a wonderful RPC protocol for doing CRUD on entities that can be roughly called 'documents', but would never dream of trying to torture some dramatically different domain into this model. When they are writing services that are document processing services they write them in a 'RESTful' style, and they otherwise never do. 2) They believe that all network transactions can be sensibly accomplished with a model that has only GET, PUT, POST, HEAD and DELETE, and that uses them as originally intended. 3) They believe that any software system that can't be accomplished as with (2) above isn't worth writing. (Web 2.0 with Rails anyone?) 4) They don't know what REST means. If #2 describes someone then he or she is inexperienced or stupid or both, if #3 describes someone then he or she is a fashion-conscious Web 2.0 asshole who will only ever receive money that came from a venture capitalist and never money that came from a customer. Ever. And if #4 describes someone then he or she really ought to read the literature before posting flippant drive-by commentary to Hacker News in what can only be some lame attempt at karma-whoring on the fashionability of the word 'REST'. > Please name one that's actually needed. Before replying to this I need to make it explicitly clear that I can only reply to what I think you're actually saying, so excuse (and correct) me if I reply to something that you didn't actually say. It sounds to me like you're proposing that GET, PUT, POST, HEAD, and DELETE are the only verbs that anyone should ever be interested in invoking over a network. Now there is a sense in which they might be sufficient for most transactions since you can attach an arbitrary payload to a POST and receive and arbitrary reply, but I think almost anyone would agree that this falls under the point made in my original post about the fact that people actually just want lightweight RPC when they talk about REST. For the sake of argument I'm happy to propose something that people might like to do with a web-service that doesn't fit a document CRUD model: play chess. Now while you may be able to GET a description of the current board with some resource identifier like /chess/game/1234/board, you will no doubt also want to MOVE and maybe even CONCEDE, and the moment that you've started POSTing to URLs that look like /chess/game/1234/move or /move/new you're right back to POSTing to a URL with another method name in it, i.e. lightweight RPC over HTTP and it's not REST anymore. The chess example is arguably contrived (and arguably not) but it doesn't take much imagination to start picturing web services for the remote compilation of code, or the provisioning of mobile devices, or calibration of remote underwater sensors. Just because a bunch of people have decided that social-networking is the most demanding application that we as developers should ever contemplate doesn't mean that the ability to do distributed message passing and procedure call is obsolete. Plenty of people are making plenty of money doing just that.