Hi Jerome, Jerome Louvel <contact <at> noelios.com> writes: > > Hi Sean, > > I don't think that there is a consensus on this point in the REST community. > > Some think that we should only rely on GET/POST as the other methods are not > well supported by browsers. We Restlet, you can always rely on the tunnel > service to dynamically change the method of request, by adding a > "?method=DELETE" query.
I should have mentioned that this is a web service so browsers don't need to be involved. Does that change anything? > Also, WebDAV already defines extension methods like MOVE: > http://www.webdav.org/specs/rfc2518.html#http.methods.for.distributed.author > ing > > Some don't like the MOVE method because the origin server may not be in > control of the target URI namespace. I like it if you restrict its usage to > target URI that you control (or return an error). > > MOVE is clearly interesting because simply doing a GET/DELETE/PUT sequence > isn't equivalent and as performant, especially when a resource has multiple > representations. > > Now, for other methods like CANCEL, we would need to understand its meaning > to be able to say whether it reduce the uniformity of the REST interface or > whether is adds a useful method to it. The result of a CANCEL is that an invoice is canceled in the DB but still available. I don't think it is a useful new method in the sense that MOVE is. I see 'cancel' as a resource state change that should be a POST (although we don't need to post any data). A DELETE doesn't seem right since we aren't deleting the invoice, just marking it as canceled. Others don't see it that way. I don't see CANCEL adding any new behavior so it's hard for me to justify. More detail. We have three operations on an invoice (that is created elsewhere). 1. Get invoice (GET) 2. Compute canceled invoice and return the savings 3. Cancel invoice >From a purely URI perspective, all I need is: router.attach("/orders/invoices/{invoiceId}", InvoiceResource.class); But the limited number of methods gets in my way. I think 1 & 2 should be a GET and 3 should be a POST. I could define a new URI, say, router.attach("/orders/invoices/{invoiceId}/cancel", InvoiceResource.class); but that seems unfortunate. Any suggestions? Thanks, Sean > Knowing that you can always tunnel those methods via a POST in Restlet > should help in such a debate! > > Best regards, > Jerome > > > -----Message d'origine----- > > De : news [mailto:news <at> sea.gmane.org] De la part de Sean Landis > > Envoyé : jeudi 12 avril 2007 00:55 > > À : discuss <at> restlet.tigris.org > > Objet : Defining Methods > > > > Restlet has the ability to define our own Methods, say MOVE, > > or CANCEL. > > I'm in a debate that is essentially arguing the merits of defining an > > application-specific Method, say CANCEL, vs. falling back on POST. > > > > I thought of 3 positions. > > 1. Only use the 4 core Methods and if that isn't enough, define a new > > URI. Problem is that this is equivalent to making the URI a verb. > > 2. Always define application-specific Methods. Be totally > > clear about what > > the application is trying to do. > > 3. Use the 4 methods whenever possible but add app-specific > > Methods when it > > makes sense. Problem I have with this is defining "When it > > makes sense." > > > > Any and all opinions appreciated. > > > > Sean > >
