Hi all,

Sorry for the rather long post,but after reviewing all the available REST
literature, I still have no answer to my rather philosophical question.

I understand that adopting a RESTful model means I have to think in terms of
manipulating addressable resources instead of thinking in terms of  function
calls. Great, but what do you do with  operations you absolutely can't refactor
according to this model? 

Specifically, operations  that involve more than one resource, and operations
that require some extra business logic (other than CRUD operation on the
resource itself).

An example of the first type of operations would be money transfer:  you want to
transfer money from account A to account B. If I were to adhere strictly to the
REST philosophy, I would either:
1)decrement A, submit A with a PUT; increment B, submit B with a PUT; and manage
the recovery process from the client should  one operation fail.
2)Create a MoneyTransferOrder object (fromAccount, toAccount,amount)and save it
with a POST.  

The former is -of course- a non-starter. The latter is just a way of disguising
an RPC call; I think it violates the REST principle in the sense that  the 
MoneyTransferOrder resource is defined for the sole purpose of passing
parameters to server-side service,  and cannot be retrieved later (i.e. it's not
really a resource).

An example of the second type of operations would be the closeAccount operation.
Maybe I want to send a notification to a manager every time an account is
closed. Again, I see two options:
1)set the isClosed proprty to True and save with a PUT. On the server, I would
have to diff the account with the value in the database, this would allow me to
detect that the account has been closed, and send the notification.
2)Create a CancellationOrder object, and save it with a POST

The problem with the first approach is that the server has to guess what
operation the client intended to complete. The second approach suffers from the
same RPC-in-disguise problem mentioned before.

Conclusion?

Well, my conclusion is that a RESTful architecture is particularly well suited
for applications where the entire business logic is done on the client  and the
server acts only has a data repository (e.g. del.icio.us).
For other applications, you'll have to leave with the fact that you may have
maybe 30% of your calls that are in fact RPC calls -i.e. a POST where you pas
the operation's name parameters. That's -from what I saw- how the upcoming.org
API is designed.


What do you Restfarians think? Am I missing the boat on this one?

Thanks,

-Vincent.



Reply via email to