Blogged on it http://service-architecture.blogspot.com/2006/12/rest-uri-naming-convention.html
Steve On 12/12/06, Steve Jones <[EMAIL PROTECTED]> wrote: > On 12/12/06, Gordon Sim <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > Steve Jones wrote: > > > > > > On 11/12/06, Gordon Sim wrote: > > > > > > > Steve Jones wrote: > > > > > > > > > > Not forbidding something means that it can't be > > > > > relied upon to be true. > > > > > > > > Why would I need to 'rely' on a URI having no meaning (to anyone, in > > any > > > > language)? > > > > > > Because if I see a URI of http://www.bar.com/foo/invoice > > > <http://www.bar.com/foo/invoice> then I'd > > > think that it referred to an invoice, unless I knew that URIs never > > > mean anything and therefore its just a random set of letters. > > > > > > > That doesn't answer the question though. I agree that you cannot rely on > > the fact that the URI has meaning (i.e. http://www.bar.com/foo/invoice > > does not automatically imply that the resource it refers to is indeed an > > invoice). But why would you need to rely on it *not* having meaning > > (i.e. that a URI like http://www.bar.com/foo/invoice does *not* refer to > > a resource that is an invoice)? > > After the first time I get burnt because someone has used /invoice and > its just a random set of letters that happen to spell it. > > Personally I think REST should mandate sensible names with resource > IDs being GUIDs that makes perfect sense to me and would clear up all > the confusion. > > > > > > >
