2008/4/28 Andrew S. Townley <[EMAIL PROTECTED]>: > > > > > > > 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.
The problem I have with this is that people are very good at making abstract decisions on what they need, computers are pretty rubbish at doing that. Its also a bit wasteful on resources in terms of network comms to have to do a root level traversal everytime I want to find news on Power Cable, Nebraska. If I know nothing of the information architecture of the system that I'm interacting with then as a person I can infer what the meaning is and then make a judgement call (potentially wrong) on what I should look at next. A machine can't make such a call. > > >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). But I don't want a given state, I want to know what is happening in Power Cable, Nebraska today and I don't want to traverse the tree. I'd also like to know when I develop my community site for PC, N how to construct that journey. A "smart" URI that helps me will mean I'm more likely to use that service than one where I have to write lots of logic to find out what I want. > > 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. I'm not sure how this makes implementation or support any easier however. > > > > 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). If however the provider publishes a specification that says http://www.cnn.com/news/local/Power%20Cable%20Nebraska will get you all the news ordered by time for Power Cable Nebraska http://www.cnn.com/weather/local/Power%20Cable%20Nebraska will get you the weather (Power Cable, Nebraska not being a resource to CNN) This means I can very quickly develop my interface and I have a commitment from CNN that this will return what I'm expecting. If my code has to go to http://www.cnn.com Which returns a set of links (what is the mime type of news or weather BTW?) and I have to work out what the current news link is, I then have to query that news link and find out what the search link is, I then have to submit my search for PC, N and get my results. Because the URI (as you seem to suggest) could be a one hit wonder then I have to make this expensive traversal each time. I thought one of the rules was that if a URI refers to something at a point in time then it should always refer to that thing? > > 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. Or the same advantages..... The effort required in building a system that would be stable while doing these traversals with no producer guarentee that the previously successful requests would result in anything doesn't sound like something I'd like to bet a B2B machine2machine marketplace on. NB I'm not saying that REST can't be used in B2B M2M (I've not see it yet) but that you'd need a higher degree of formalism than just relying on hypermedia. Steve > > *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 > >
