Mark Baker lays out a hint of things to come:
I still hope to respond to his earlier response to a question of mine, in what will likely end up being a mini treatise on state and state references. But that’ll have to wait.
Don’t wait too long, Mark. I’d really like to see that article!
My recap of the processThis concept seems to have been interpreted as a suggestion for how I think things should be. To the contrary, I wrote it as a tool to verify that I understood what Jim and Savas were saying, not in advocacy of the scenario described.
I did so because I think there might be an impedance mismatch in the ongoing conversation, and I wanted to be sure I understood. Mark is making inroads to clarification as he addresses Savas’ model of GET:
I think the comparison between HTTP request/response and “processMessage” is incorrect; the comparison should be between HTTP POST and “processMessage”.
I perceive at least three possible interpretations of processThis, and it might help if the parties involved clarify which they mean (or give other choices altogether):
processThis has an input and an output, both of which are unconstrained.processThis has an input which is unconstrained and a status output.processThis has an input which is unconstrained and has no output.I described (1) in my recap, and Jim Webber seemed to approve. I predict that Mark Baker sees (2), the equivalent to HTTP POST. And I suspect that Savas sees (3), by virtue of his Web Services model for GET.
Savas worries about embedding URIs in resource state:
My worry about this approach is that there is a coupling of an identifier (the URI), an interface (HTTP verbs), and the state on which these verbs operate. The approach may work for the web but as we attempt to build large-scale, distributed applications that do not involve the human factor, we may get complex networks of references between the states of resources containing references to other resources which, in turn, may lead to brittle applications.
A service that depends on being able to dereference a URL embedded in its state is indeed susceptible to failure if the authority serving the URL is unreliable. For example, step three of REST goes to Maui depends on being able to dereference the POSTed Reply-To, Status-To, and payment URLs. Is that an accurate summary of your concern, Savas?
It’s a good point and something that REST designs need to address if they depend on URLs. I would expect similar issues among aggregators of Web Services. How would you address the possibility that a Web Service might stop returning messages in a certain format or just suddenly cease to exist? I am hopeful that general principles to solve this problem in Web Services might yield clues to solving it in REST as well (or vice versa). Anyone care to offer a design pattern that addresses this?
URNs are not protocol specific, while URIs carry some protocol specific information. Also, we do not assume a coupling of the identified resource and the means by which the resource can be accessed.
URI, URN, URL–I try to be very careful to use URL only when I’m talking about a locator, and URI for everything else. I don’t typically use URN because we are increasingly using HTTP URIs as URNs. XML Namespaces and RDF, for example. I conjure up a URI by fiat:
http://www.geekaboo.net/names/garland/matt/
It doesn’t necessarily locate anything, it just identifies/names me or whatever else I choose for it to represent. A nice side effect is that it may locate something, but again, if I want reliability, I really shouldn’t depend on what it locates being anything in particular.
This usage is normative. The URI spec section 1.1 is clear that the “uniform” in URI (of which URN is a subset) means that URIs can be reused in contexts other than the protocol for which they were originally developed. Section 1.2 goes on to say that URIs can be both locators and names at the same time.
Savas’ advice to use URNs sounds good to me, but note that RFC 2396 permits me to use HTTP URIs (treating them as URNs) to the same effect. Whether I choose to couple that HTTP URI to the HTTP protocol is really just an implementation detail.
Mark Baker, how do you deal with these issues?