I have a feeling you're seeing a problem where there actually is none. A URI is an identifier, much like a variable identifier in a programming language.
Having a variable named "ajkshdkajshd" is probably a bad idea, having "SecondaryShippingAddress" is probably much better. Using reflection mechanisms and string parsing methods to extract the word "Secondary" from the identifier to drive application logic is probably a bad idea, though. From the point of view of the programming language, identifiers are "opaque" in the sense that the characters just have to follow the syntactical rules, nothing more - from that POV they are meaningless. Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/ On Dec 6, 2006, at 5:26 AM, Steve Jones wrote: > On 05/12/06, Jan Algermissen <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > On Dec 5, 2006, at 12:36 AM, Steve Jones wrote: > > > > > This to me is a cop-out, either URIs should be meaningful in > REST or > > > not, having a half-way house of "kinda" doesn't help anyone or > add any > > > sort of clarity and formalism. > > > > Dunno, but I think it has been said before in this thread that > from a > > REST POV, URIs are simply opaque identifiers. > > So in other words it is _important_ for REST that the URI be > meaningless? (http://www.askoxford.com/concise_oed/opaque?view=uk) > > opaque: difficult or impossible to understand > > So surely this means that the examples I used with sensible names that > mean something are therefore _not_ REST as they are easy to > understand. > > Given therefore that REST URIs are meant to be unintelligable (which I > really don't understand as to why that is a good thing) how do you > communicate to consumers what URIs to use? What is the way of > documenting URIs to consumers? > > > > > Jan > > > > > >
