On Mon, 2008-04-28 at 10:48 -0400, Anne Thomas Manes wrote: > I have to disagree with you Andrew. > In fact, the URL of the mail I'm looking at right now is > http://mail.google.com/mail/?hl=en&tab=wm#inbox/11994a7d8005175b. That > URL refers to the mail thread in my inbox with the subject line "URI > design (Was Re: [service-orientated-architecture] Re: Meehan on WOA > and SOA)". > > Now perhaps your are distinguishing between URLs with and without > query strings. Note that gmail uses a query string after the > "http://mail.google.com/mail/"; to refer to my various mailboxes and > specific letters. Nonetheless, the URI with a query string is still a > distinct URI representing a resource.
No, actually I wasn't making any such distinction. I wouldn't dispute your assertion about URIs, either. :) > I find your terminology interesting, though, when you say, "each > human-readable URL should be a separate *service*." I agree that > "mail" in this case is the service. But I'm not convinced it's > appropriate to tie a service to a specific resource. The resources > exposed by a service constitute its interface. Applications interact > with the service via its resources. Ah, yes, but here we're back to the abstract nature of the service vs. the concrete implementation of the service provider. The model I was trying to describe wouldn't tie "mail" - the mental model I have of the electronic postbox - to a particular URI. Instead, it would be something that you would find offered by a number of different URIs, e.g. I can get mail from any of the following: http://mail.yahoo.com http://atownley.org/webmail http://archistry.com/webmail Each one provides me a mail service that I can access from any of those resources. Of course, it isn't the same concrete implementation with the same information, but it still provides the same conceptual, abstract service. How do I know they provide the service? Someone told me they do, and I've since validated that assertion. That's a different problem. The core distinction I'm trying to make here is the difference between an "external" interface to a service, and the "internal" interface to the service which is a consequence of how it's implemented. If I go to cnn.com, I'm expecting to get a news service (the QoS is always questionable), but I don't have to know the URIs that provide me the implementation of that service, nor should I be able to infer them or otherwise try to "guess" to try and find the sub-set of the news I want. The service should provide me a way to access the resources of interest without me needing to know anything about its information architecture. That's why it's hypermedia and not an API. >From a pragmatic point of view, this is also why search and the permalink concept exist, so that you can provide well defined, and relatively stable ways to access hypermedia application states. This added constraint enhances interaction with the service because it allows you to "freeze" a part of the application state at a point that the service provider is willing to support. It still only works with mutual agreement that such functionality will be offered by the provider (maybe it's a live video stream). Also, the nature of HTTP ensures that as long as I can connect to the server, I'll *always* get a resource for the URI--it may not be the one you expect, but that doesn't mean it isn't a valid resource. Too many times when people talk about non-opaque URIs, there's a lot of implicit assumptions and semantic coercion involved that just shouldn't be there. Treat URIs as opaque identifiers, and those assumptions are harder to make. > But going back to my previous example of customers, orders, and parts, > I would refer to the entire system as an order management service, and > it provides multiple paths to access the resources offered by the > service. I agree with you about the service, but how it does what it does should be irrelevant if I know how to follow links. Where we seem to disagree is the degree of semantics that should be associated with a particular URI and the extent a client (human or otherwise) should be able to make assumptions about the content associated with any particular URI or the operations that it supports. By their very nature, URIs are always ultimately under the control of the URI resolver, and, if that service follows the HTTP spec, you'll always get a resource (or it has fallen over, and that's a different problem). I'm not saying there aren't missing pieces in how you determine what links you follow, but I think if you're building software based on formatting strings on a client to generate non-opaque URIs you expect to be valid on the server, 1) you'd better be in control of both ends of the equation, and 2) you're not building a hypermedia application. Of course it'll work--to a point. However, it's still an API and you're going to still have all of the same issues we've had with APIs for the last 30 years. *oink* ;) > Anne > > On Mon, Apr 28, 2008 at 2:55 AM, Andrew S. Townley <[EMAIL PROTECTED]> 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 should be your electronic mail, but you shouldn't > > go as far as 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 URI design is difficult to do well, because it's based on a set > > of assumptions that may change over time. Many times I've thought I had > > a good strategy designed that eventually broke down for some reason as > > the site/service evolved. Keeping the URIs that encourage users to type > > them into the browser to the minimum helps you more gracefully evolve > > your service. For the most part, once the user is using the service > > (automated or interactively), the URLs shouldn't matter much as long as > > they're pretty stable. If users regularly need to type opaque URLs in > > to a browser, there's a problem with your service design and information > > architecture rather than with the URL. > > > > Cheers, > > > > ast > > > > On Sat, 2008-04-26 at 05:33 +0000, Rob Eamon wrote: > > > Ah, I see. Much like "intelligent keys" where a caller assume chars 4- > > > 11 are the account number so they don't query for the account number. > > > Makes sense. > > > > > > Thanks for the info! > > > > > > -Rob > > > > > > --- In [email protected], "Andrew S. > > > Townley" <[EMAIL PROTECTED]> wrote: > > > > > > > > On Fri, 2008-04-25 at 14:53 +0000, Rob Eamon wrote: > > > > > > But I much prefer this URL to something truly opaque like: > > > > > > > > > > > > http://www/example.com/123453456234511111 > > > > > > > > > > Perhaps you've covered this before, but what is the rationale > > > > > behind using an artificial key in this context? > > > > > > > > > > > > > You mean besides ensuring that whomever is using it can't make any > > > > assumptions about the URL and they have to treat it like "just" an > > > > identifier, e.g. URI? ;) > > > > > > > > While they can be useful, inferring semantics from a URI without a > > > > specification that says you can and a commitment to ensuring the > > > > spec is followed is to start down a slippery slope sure to end in > > > > disaster (and spending a lot of money at some stage). > > > > > > > > It also gives you more architectural flexibility in your > > > > implementation without having to support a bunch of different URI > > > > namespaces. > > > > > > > > There are other advantages, but those are the primary ones I see. > > > > > > > > HTH, > > > > > > > > ast > > > > -- > > > > Andrew S. Townley <[EMAIL PROTECTED] > > > > http://atownley.org > > > > > > > > > > > > > > > > ------------------------------------ > > > > > > Yahoo! Groups Links > > > > > > > > > > > -- > > Andrew S. Townley <[EMAIL PROTECTED] > > http://atownley.org > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > -- Andrew S. Townley <[EMAIL PROTECTED] http://atownley.org
