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.
