> 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.

Reply via email to