But this is a big problem, there is no such thing as "maybe" for computers and people will always read meaning into names. If naming is important then it is always important, if naming isn't important then you should obfuscated names to stop people getting confused.
If REST is about meaninful names then they should _always_ be meaningful, not optionally meaningful. And if names are obfuscated and not meaningful then how do you communicate to clients what the URI actualy means and what request they should make? I'm getting more confused here rather than less! On 03/12/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote:
The preferred way is to have the server create the links. This way, it's under the server's authority to redirect you to other hosts without you caring about it. The moment you add meaning to URIs, you risk that a client will construct them by adding component parts to root parts ... relying on assumptions you don't want them to rely on. Still, having meaningful URIs makes life easier for everyone. You just have to be aware of the risk :-) Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/ On Dec 3, 2006, at 4:23 PM, Steve Jones wrote: > Hang on, I'm getting different advice here, my understanding was > that URI naming (picking good names) was an essential part of > REST. If its an internal identifier then that isn't the case. > > So should REST URIs have carefully chosen names, or is banging at > the keyboard randomly the prefered approach? > > > > On 29/11/06, Jan Algermissen <[EMAIL PROTECTED]<jalgermissen%40topicmapping.com>> wrote: > > On Nov 28, 2006, at 11:40 PM, Steve Jones wrote: > > > o you are saying that it is _bad_ practice in REST to have sensibly > > named URIs? > > URIs are opaque identifiers (just like object references in any OO > language). You should > not infer anything from a URI. > > Jan > > > > >
