On 9/15/06, Vincent <[EMAIL PROTECTED]> wrote: [...]
Sorry for the rather long post,but after reviewing all the available REST literature, I still have no answer to my rather philosophical question.
No worries. It's a good 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?
If you come to that conclusion then, most likely, you've found a weakness in the model of what you're trying to do. I hate to say it but, IME, this sort of problem comes up when trying to force pre-existing "paradigms" into the REST model. Its a struggle we've all had to face so you're in good company.
Specifically, operations that involve more than one resource, and operations that require some extra business logic (other than CRUD operation on the resource itself).
A good philosophical point to remember is that "resources" are *not* constrained to match any underlying implementation. I.e., a resource may well be something more abstract and complex (like a "view" in a database like Oracle).
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.
Actually, no on both (though the second is closer). On the source account, you'd initiate a transfer with the arguments being the target account and the amount. The result on success would be that specific transfer's ID. [...]
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.
You authenticate and then post to the account's close. Assuming you're not doing a multi-step close, then the server would do whatever's needed to close the account (including sending the notification).
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.
Aha! Well, that certainly explains part of the confusion! That's a bad example. Their approach *is* basically a simplistic RPC over http approach. You might want to look at the Atom protocol for a good example. FWIW, Dave Johnson's book "RSS and Atom In Action" has recently been published by Manning (though, I'm biased since I was a reviewer of it). You might also want to look around for the various discussions of good (web) "information architecture". The best web IA intersects directly with good REST design. Hope this helps, John
