On 08/12/06, Gordon Sim <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
> Steve Jones wrote:
>  > opaque means that URIs should be meaningless, so all sensibly named
>  > URIs are therefore not REST.
>  [...]
>  > But if its easy to remember then its not opaque (even sensible + GUID
>  > isn't opaque).
>
>  To me opaque just means non-transparent.
Which means you can't see what is behind it, so (to use the 2nd part
of the definition http://www.askoxford.com/concise_oed/opaque?view=uk)
it is difficult or impossible to understand.

> 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.  Not forbidding something means that it can't be
relied upon to be true.

>
>  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 to refer to a particular resource is no
>  better than using 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.

Either URIs should be well named, or they should be obfuscate, a
half-way "I wish" house is not a good foundation.

>
>  If *other* requirements (e.g. making the URI easy to remember or
>  meaningful to a human doing some debugging or auditing) require adding
>  meaning to the URI, thats fine.

But not required.  For me if REST is serious for commercial definition
then the URI should be meaningful and should be (in effect) strongly
typed.  This would make it easy to split between the good and the bad
URIs rather than having an "anything goes" mentality that can only
cause grief.

>
>                    

Reply via email to