Hi Vincent, You are indeed asking a good question, not because you are reaching any "limit" of the REST/HTTP style but because you have a case where there is no simplistic separation between REST and RPC styles.
At the most abstract level, REST doesn't force the use of any protocol (though HTTP is the de facto standard) nor any identification mechanism (though URI is the de facto standard). Also, in REST, any identifiable concept (meaning anything stable and useful enough to have a name). Think about a Resource as the Object class in Java for example: anything is an Object, whether you want it or not. At a lower level, REST applied on HTTP doesn't even constrain your to only use GET/POST/PUT/DELETE and other predefined verbs. If you really need it, you can perfectly use new verbs like MOVE or COPY. This is exactly what the WebDAV extensions are using. HTTP allows for this in its spec. Now, like a Web page can allow a user to edit a form, then to post it to a processing resource, you can require your clients to edit more complex forms (XML using XForms for example) and then to POST them to a processing resource. This is RESTful. You can even view XML-RPC as a RESTful application using a subset of the REST/HTTP features: it's simplistic because it doesn't allow linking, doesn't take advantage of GET caching, content negotiation, etc. Still, in XML-RPC, you are POSTing a sort of "ProcessingRequest" document to a "ProcessingManager" resource. It's not that different from a "PurchaseOrder" document POSTed to an "OrderManager" resource. 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. Hope that helps, Jerome > -----Message d'origine----- > De : news [mailto:[EMAIL PROTECTED] De la part de Vincent > Envoyé : lundi 18 septembre 2006 05:53 > À : discuss@restlet.tigris.org > Objet : Re: Re: How to compromise when designing a RESTful API? > > > > > I think the approach you're advocating forces the client to > know way more about > the server than it should, and to make it do way more work > than it has to. > > > > > POST /transfer/account/123 > > > Host: myserver.com > > > Content-Length: XXX > > > <toAccount>456</toAccount> > > > <amount>300</amount> > > > > > > > It *seems* like you're passing an action, but IMO what > you're actually > > doing is turning the action into a resource, which is very > powerful. > > That resource has a unique address, a state that can be > transferred, and > > is only manipulated with our four magic verbs. You can even make it > > asynchronous by posting a transaction and polling for its > status later > > at the resource's URL. > > > http://tech.groups.yahoo.com/group/rest-discuss/message/6561 > > So, you're suggesting that a URL like > /transferMoney/account/123 is indeed a > resource, especially if it is used in conjunction with a > transaction (as > Benjamin suggested in his post): > client -> server: POST /transferMoney > server -> client: created; location: > http://myserver.com/transferMoney/789 > client -> server: PUT /transferMoney/789 > <fromAccount>123</fromAccount> > <toAccount>456</toAccount> > <amount>300</amount> > > The fact that the transfer happens inside a transaction is a > server concern; the > client does not need to have this knowledge. Plus, it forces > the client to make > 2 calls instead of one. > > > > > > And what if I want to close all accounts that have been > > > inactive for at least a year, without retrieving them one by one? > > > Would this approach: > > > > > > > If you don't want to retrieve them one by one I think you > can do the > > same thing, invert an action into a resource with something like: > > > > GET /accounts/?inactivityPeriod=365 > > > > You get back a set of account URLs: > > > > <accounts> > > <account link="/account/1234" /> > > <account link="/account/1235" /> > > <account link="/account/1236" /> > > </accounts> > > > > Which maybe you can POST to an 'account closing' resource: > > > > >> > > POST /account-closer > > <accounts> > > <account link="/account/1234" /> > > <account link="/account/1235" /> > > <account link="/account/1236" /> > > </accounts> > > > Here are the issues I see with this approach: > - you force the server to expose an extra search API > - the result set could be huge. > - increased traffic between the client and the server > - you still have a RPC-sounding resource (the accountCloser) > > > > Or whatever. I'm pretty sure this isn't gospel, but it > makes sense to > > me, and I think demonstrates the power of the 'resource' > abstraction. > > Hmmmm, it seems to me that you're bending to API to make it > fit the REST model, > to the point where you end up breaking the abstraction layers > (client knows/does > too much). > I'm a REST newbie, so I might very well change my mind and > adopt your point of > view, but -at this point- I'm still unconvinced by this > 'action as a resource' > approach. > > -Vincent.
