On 06/12/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote: > > > > > > > On Dec 6, 2006, at 5:27 PM, Steve Jones wrote: > > > On 06/12/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote: > > > > > > 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. > > > > Which means that it is critical that the name is sensible (i.e. not > > opaque). > > > If a human is supposed to read, write or remember that URI, I think > you are right.
And as URIs in REST are to be used by developers this surely means pretty much all URIs should be sensible. > > > > > > > > > > > > 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. > > > > But if you have PrimaryShippingAddress and SecondaryShippingAddress it > > is sensible for a developer to have an "if" statement that checks if > > Primary is valid and ships to Secondary if not. > > > I see the analogy didn't get my point across. Let me try differently: > Your client program's code, at development time, should, as a rule, > not build or interpret URIs from components. It should always use > URIs provided by the server, either as results of creating new > resources via POST, or in the form of hyperlinks. (The server, of > course, will build URIs as needed). Completely agree, so what we are both saying here is that when developers build code then the URI should be sensible. To me this indicates that the server created URIs should also be sensible (to help debugging et al) or at least sensible upto a point (i.e. with a GUID at the end or something). > > > > > > > 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. > > > > Not at all, the aim of them is communication to the developer and not > > to the compiler. For this reason they are a long way away from being > > opaque. > > > > Either REST says that URIs need to be sensible and meaningful names or > > its okay to have rubbish and there is another bit that gives meaning. > > The fact that someone can do something badly (e.g. have a bad variable > > or method name) doesn't mean that this should be the standard. > > > No, and it's not "standard" to have strange URIs. It is common > practice to have meaningful URI parts, simply because it makes them > easier to handle. Thank god for that, I was beginning to think that REST was for people who thought Perl was too readable! > > > So should REST URIs have meaning or are they opaque? > > > REST does not require them to be opaque, but basically forbids you to > rely on any meaning they might have (or can be interpreted to forbid > that, depending on whom you ask). The later part of the sentence sort of contradicts the earlier part. What you appear to have said is "URIs are sensibly named but the names mean nothing" is that right? If the URI doesn't therefore have any reliable meaning, how is meaning communicated to consumers? > > Stefan > -- > Stefan Tilkov, http://www.innoq.com/blog/st/ >
