Interesting blog, Steve but not as hilariously entertaining as Heather's (your wife?):
http://hboutique.blogspot.com/ She could write a seriously successful newspaper column! Gervas --- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> wrote: > > 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. > > > > > > > > > > > > >
