Hi Vincent, I have copied this to the rest-discuss list as well.
> 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). REST is not just about CRUD operations on resources identified by a URI. I have made some comments on this in a previous post to the rest-discuss list. http://tech.groups.yahoo.com/group/rest-discuss/message/4573 A few people give the impression that GET/PUT/DELETE/POST(a) is the "true REST way" and that GET/POST(p) is the dark side. This ignores the fact that the most successful REST style Application framework (HTML over HTTP) uses GET/POST(p) almost exclusively. /* POST(a) = append to the URI, POST(p) = process this. */ Now, you can think of POST as a "disguised RPC call" and in the trivial case it is similar, but that ignores other possibilities for the use of POST. A Resource is not necessarily a discrete entity on the server (such as a file). It may be a view onto a number of entities on the server, similar to a database view over a number of tables. Benjamin Carlyle gives an excellant description... http://tech.groups.yahoo.com/group/rest-discuss/message/5972 So if you implement a resource as a view onto a set of related entities in your domain model, then updating or POSTing to that view can modify many entities at once, execute your business logic and wrap the whole lot up in a transaction. (by domain model I mean the business data and logic implemented on the server) Thinking of it another way, you are telling your domain model what you want to achieve, not how you want to do it. > 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. 3) POST an instruction to your account, represented by a URI, with instructions to transfer an amount of money to another account, represented by a URI. This may create a new resource representing the transaction. The success/failure of the operation will be returned in the response body along with the URI to the transaction. There is no "REST says you must create a transaction" but in this case it is probably a good idea. > 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). Nothing, anywhere says that POST must create 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 When using a POST as a "process this" operation you can send a request to your account URI to close the account and the business logic that closes the account can send a notification to any other interested party by POSTing another request to their URI. In this case your Account and the Manager may be on opposite sides of the world. You just don't care when you are using URIs to address resources. > 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? > I hope you can see that POST is a bit more that a substitute for RPC. I have not commented on PUT/DELETE/POST(a) here but I do not diminish their role either. As you have observed, they have limitations. They have similar qualities to other Data Service mechanisms, like Relational Databases, in that you can store data and have the data checked for type correctness and referential integrity, but you cannot use them to implement business logic. At least, not without a lot more effort than is worthwhile. I am not suggesting that there is a clear delineation between these groups of HTTP methods. They can be used intermixed, but I believe it helps clarify your thinking to view them in this way. As far as HTTP is concerned there is absolutely no difference between POST(p) and POST(a). The transfer protocol does not care what you intend to do with the request. The transfer protocol only cares that the request is unsafe, not indempotent and that you cannot cache the responses. Part of the confusion about REST has been that people have taken an Architectural Model for the internet and tried to use it to evaluate distributed applications when it was intended to evaluate transfer protocols. The constraints that dictate the desired behaviour of User Agents, Proxies and Origin Servers don't always map well to Banking application and Wikis. REST is not about the Atom protocol. That is an application protocol. But the Atom protocol has been designed with REST in mind. My understanding is that the Atom protocol does not use the "process this" version of POST. Thats fine. HTML does not use PUT or DELETE. Both could be described as RESTful applications but neither of them defines REST. Regards Donald. National Australia Bank Ltd - ABN 12 004 044 937 This email may contain confidential information. If you are not the intended recipient, please immediately notify us at [EMAIL PROTECTED] or by replying to the sender, and then destroy all copies of this email. Except where this email indicates otherwise, views expressed in this email are those of the sender and not of National Australia Bank Ltd. Advice in this email does not take account of your objectives, financial situation, or needs. It is important for you to consider these matters and, if the e-mail refers to a product(s), you should read the relevant Product Disclosure Statement(s)/other disclosure document(s) before making any decisions. If you do not want email marketing from us in future, forward this email with "unsubscribe" in the subject line to [EMAIL PROTECTED] in order to stop marketing emails from this sender. National Australia Bank Ltd does not represent that this email is free of errors, viruses or interference.
