4 ms·

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

• 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.
  • ratsbane 19y ago
    In a RESTful world you might thing of moving a chess piece as POSTing a new location value to /chess/game/1234/piece/. To concede, You could POST a "concede" flag to /chess/game/1234. That seems to me like the simplest way to state the actions, but I'm sure there are many semantically equivalent ways to accomplish the same thing.
    • benreesman 19y ago
      When you say out loud or write in English what you intend to do you will say 'I moved my piece from b2 to b3'. When you invoke a method to accomplish this inside of a single process you say (move piece :b3) or piece.move(:b3). Why then, when the network gets involved do we do the semantic gymnastics to recast this to 'I posted a document describing a move that a piece could take to a resource identifier describing such a piece'? Why would 'piece' even be a distinct resource in the first place? What would come back if you GET a piece? I'll argue that 'piece' is only a resource so that it can serve as the implicit first 'self' argument to the 'move' method call. My assertion is not that it is impossible to torture some domain into a document centric model, I'm just saying that the limit of your motivation for doing so as the distance from 'document' to your specific domain goes to infinity is 'fashion'.
      • ratsbane 19y ago
        REST does have an advantage over SOAP in that it more easily takes advantage of the properties of the HTTP over which it runs: verbs, caching, etc. With REST it's very easy to separate requests which change data from those which don't. Also, it's usually more concise. I think it's easier to code for REST than SOAP, although, by choice, I've done more of it. I have worked on some SOAP processes; while I concede it's easier to drag-and-drop SOAP objects in an IDE, the verbosity of the ensuing transactions makes it easy to overlook errors and much harder to fix them. It may be more fashionable to use REST (although I know of some circles where the opposite is true) but just because a trend is growing doesn't means it's bad. REST seems like more of a grass-roots trend while SOAP is more something that's sold to its users (that's just my impression; I'd be glad to hear arguments to the contrary.) There are a lot of technologies you could describe as more "fashionable" because their use is growing - but their intrinsic merits or suitability for an emerging purpose might be the cause of that - e.g. the web, email, pork-based cocktails. Er, strike that last one.