On 11/12/06, Gordon Sim <[EMAIL PROTECTED]> wrote: > > > > > > > Steve Jones wrote: > > > > > > On 08/12/06, Gordon Sim <[EMAIL PROTECTED] > > <mailto:gordon.r.sim%40gmail.com>> wrote: > > > > > > For an opaque identifier, any > > > 'meaning' which may be encoded in it (beyond its use as a unique > > > identifier) is irrelevant (and in any case not visible) to the system or > > > model to which it is opaque. It is not forbidden that some meaning may > > > be discernible by some other system or model (e.g. the english > language). > > > > Not forbidden is a strange phrase. Naming conventions in programming > > languages almost always mandate that names _always_ be sensible and > > convey meaning. > > REST is not a naming convention for a programming language though.
But the same principles applies as the names refer to resources etc. > > > 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 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. People make assumptions, names are a great way to get people to make assumptions. > > > > > > > So as I understand it, from the perspective of the requirements placed > > > on a system if it is to meet the REST architectural principles, using > > > http://myserver.com/invoice <http://myserver.com/invoice> to refer to > > a particular resource is no > > > better than using http://myserver.com/akjofjm, > > <http://myserver.com/akjofjm,> neither is it any worse. > > > > Which means that you have to (for REST) assume the latter as there is > > nothing to say that http:.//myserver.com/invoice isn't just a random > > set of letters that just happen to spell an english word. > > It means that, _in_my_understanding_ of the statements made by REST > experts on this list, one is as RESTful as the other. Other > considerations may affect your choice between the two of course. This is a cop-out IMO. Given that the URI is so important in REST it would be logical to me that REST URIs should always have a level of meaning, appending a GUID for a resource would indicate uniqueness, but having sensible names is just... well sensible. Saying there is no URI naming standard when the URI is such an important element is very odd. > > > Either URIs should be well named, or they should be obfuscate, a > > half-way "I wish" house is not a good foundation. > > I don't follow your logic here. Are you arguing that because REST does > not include any constraint *requiring* meaningful URI names (which as I > recall was the misconception that led to this thread) it should > therefore *require* them to be obfuscated? Yes. By making it optional it in effect requires people to assume the later. Personally I'm suprised that the answer wasn't "sensible names with a GUID as the resource identifier". >
