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. 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. 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:[EMAIL PROTECTED] De la part de Sean Landis > Envoyé : jeudi 12 avril 2007 00:55 > À : [EMAIL PROTECTED] > 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
