Andrew S. Townley wrote: > > > Exactly! > > I agree Nick's comments on opaqueness, and I think he said it pretty > well. I think the number of URLs that you make "human friendly" and are > prepared to support from a system perspective should be kept to the > minimum that makes sense. > > This is a trade-off, of course, but my rule of thumb is that each > human-readable URL should be a separate service. For example, > http://mysite.com/mail <http://mysite.com/mail> should be your > electronic mail, but you shouldn't > go as far as http://mysite.com/mail/inbox. <http://mysite.com/mail/inbox.> > > This also comes back to my (much at this stage) earlier thoughts on REST > APIs, because you should only need to give the client a well-known URL > as the entrypoint and then it should only be able to do what the service > tells it it can via hypermedia exchange. If you expose URLs to > spidering, that's a bit different in that you have to make a commitment > to supporting them once they're made public. However, that doesn't mean > that URLs that aren't the "front door" to your service are good > candidates for being non-opaque.
I think this is a good example of just designing operations verses designing interfaces. Interface based design removes all problems with deciding what a service has to support. If the interface based design includes the base functions that you want to support, then you know what to expect. If, instead, you design at a higher level of operations with more complex actions, then you have to make sure you cover everything that a client would want to do with the data that your service exposes. For me, this is where opaque URIs break system design. They make it possible to "hide" functionality in a way that removes interface based design. Gregg Wonderly
