3 ms·

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" f

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.
  - benreesman 19y ago
    I'm not generally an advocate for SOAP. SOAP is good for basically one thing, which is sending Java/C# objects over HTTP and having them arrive on the other side looking the way you expect. My preference for languages like JavaScript leads to a preference for lightweight (mostly JSON-bearing) web services that most people would call REST. I agree that SOAP has been the subject of way too much promotion of the part of tools vendors trying to sell bloated web-services stacks. The reason for my rant is that REST has become a battle-cry in some kind of reactionary anti-vendor uprising, which obscures the issue. The word REST has a very precise meaning and almost all of the celebrated 'REST' services (Flickr, Amazon, Facebook, etc.) fail to meet the criteria. Those services are just lightweight RPC over HTTP, and there's nothing wrong with doing a service like that. For client programs written in 'dynamic' languages, those kind of services are preferable. REST is for documents, and time spent trying to find the 'resource' to be POSTed to in 'finalize this multi-step transaction between these two interest-bearing accounts' is time wasted. The linguistic gymnastics necessary to jam an RPC peg into a CRUD hole just make the service developer look silly. Cheers.
    - johnm 19y ago
      Indeed, a lot of the services touted as RESTful are less RESTful and more RPCish. REST has certainly become a fad term that's used to hype that anti-SOAP juggernaut and that's led to a lot of confusion since so many of the folks doing the yapping don't really understand REST. Your confusion (whether you've read Roy's dissertation or not) seems to be a fairly common one for people coming from an experienced RPC mindset. I had a similar conversation at SDWest after my talk on REST with a SOAPer -- he too was missing the point that terms like "document" and "resource" are much more abstract in REST than what the general English meaning implies -- particularly to people who's existing experience with RPC approaches like SOAP and CORBA before that gives them a very different and, arguably, much more concrete terminology for RPC.

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.
- benreesman 19y ago
  I'm not generally an advocate for SOAP. SOAP is good for basically one thing, which is sending Java/C# objects over HTTP and having them arrive on the other side looking the way you expect. My preference for languages like JavaScript leads to a preference for lightweight (mostly JSON-bearing) web services that most people would call REST. I agree that SOAP has been the subject of way too much promotion of the part of tools vendors trying to sell bloated web-services stacks. The reason for my rant is that REST has become a battle-cry in some kind of reactionary anti-vendor uprising, which obscures the issue. The word REST has a very precise meaning and almost all of the celebrated 'REST' services (Flickr, Amazon, Facebook, etc.) fail to meet the criteria. Those services are just lightweight RPC over HTTP, and there's nothing wrong with doing a service like that. For client programs written in 'dynamic' languages, those kind of services are preferable. REST is for documents, and time spent trying to find the 'resource' to be POSTed to in 'finalize this multi-step transaction between these two interest-bearing accounts' is time wasted. The linguistic gymnastics necessary to jam an RPC peg into a CRUD hole just make the service developer look silly. Cheers.
  - johnm 19y ago
    Indeed, a lot of the services touted as RESTful are less RESTful and more RPCish. REST has certainly become a fad term that's used to hype that anti-SOAP juggernaut and that's led to a lot of confusion since so many of the folks doing the yapping don't really understand REST. Your confusion (whether you've read Roy's dissertation or not) seems to be a fairly common one for people coming from an experienced RPC mindset. I had a similar conversation at SDWest after my talk on REST with a SOAPer -- he too was missing the point that terms like "document" and "resource" are much more abstract in REST than what the general English meaning implies -- particularly to people who's existing experience with RPC approaches like SOAP and CORBA before that gives them a very different and, arguably, much more concrete terminology for RPC.