> Think about a Resource as the Object class in Java for example: > anything is an Object, whether you want it or not.
Yes, but objects have state *and* behaviour. All the REST articles I’ve seen so far conveniently ignore the behaviour part by carefully choosing examples where the server does not need to perform any business logic (e.g. the ATOM protocol, which is touted as the ultimate REST application). It seems to me that all these articles are saying is ‘use setters on your objects, and save the object when you’re done’. This forces me to do: rectangle.setCenterX(12); rectangle.setCenterY(34); rectangle.save(); When what I really want to do is: rectangle.translate(4,6); > In conclusion, try to think in term of resources addressable by > URIs and document exchanges instead of remote objects and remote > method calls. The documents can be either the representations of > resources or the representation of the intended state of a resource, > or the entity to be processed by a processing/service resource. I interpret this as: whenever you find yourself needing a semantic richer than what setters have to offer, use the Command Pattern AND treat commands as resources. At first sight, it seems to me like turning a command into a resource is just a trick that allows you to say ‘oh no, no, no, I’m not using RPC at all! I’m a true RESTfarian, you see’. Now, a very good reason why I would want to turn a command into a command would be to guarantee idempotence. The scenario would be: client -> server: POST /translateCommand server -> client: 201 Created server-> client: Location: /translateCommand/12 client -> server: PUT transalationCommand/12 <objectId>45645</objected> <transalateX>4<translateX> <transalateY>6</translateY> The server records the transaction status, and simply ignores any further attempts to re-execute the transalateCommand with id #12. But if I start going down this path, I’ll want to use the same mechanism for creating objects. So, to create a rectangle, I no longer POST a Rectangle resource but PUT CreateRectangleCommand, get transaction id, and PUT the command with the rectangle id, and the X, Y info. So, trying to think in RESTfarian terms let me to confine POSTs to the creation of commands. Back to banging my head on the wall.. Thank you all for your great input, it really in my journey towards a more RESTful world. -Vincent.