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. > 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)? > > > > 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. > 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?
