Ok then, I’ll offer my opinion. I don’t think it’s possible (to describe protocol independence as a constraint), because I believe that the choice to be protocol independent is an implementation decision without implication for the properties of the architecture in use. The decision to be protocol independent or not is therefore primarily one of how best to integrate with the existing Web and Internet.
Oh come on, somebody had to say it. 8-)
Not much to see yet, but they’re writing a couple of papers, one of which will go into detail about MEST’s architectural constraints, permitting us to evaluate its suitability at large scale, it’s relationship to REST, etc..
Here’s a challange for fans of protocol independence; try to describe it in strict architectural terms, i.e. in terms of constraints applied to components, connectors, and data.
David Orchard again tries to defend the Web services stack by analyzing where service-specific state-setting operations are required. His conclusion is unsurprising;
This article has shown that specific write operations are the correct interface design choice for many complex update operations. There are also constrained situations where generic update operations such as HTTP PUT provide superior value. There is no single correct or canonical way to model an interface.
To which I would reply – modulo the choice of the word “many” there – “Of course”. But still, I think the point of generic vs. specific is missed; that generic (PUT in this case) hits an 80/20 sweet spot (give or take). That’s all I’ve ever said, along with the comment that because it’s a sweet spot, it should be the starting point for the Web services architecture, and therefore reified as an architectural style.
That said, there are a few misconceptions in Dave’s post that I’d like to address.
The put timeout operation has an input of the time requested, and an output of the granted timeout.
That would violate PUT semantics. A successful PUT response tells the recipient that the state of the targetted resource was changed to the state reflected in the provided representation. The body of a PUT response can say other things in addition to this, but nothing which violates this contract, as a “granted timeout” would do. Update; actually, there might be a way to do this uniformly, but I don’t think it would provide the expected semantics Dave’s going for since it would require that the timeout was actually set to the provided value at least for the instant in time that determined a successful response could be returned.
Setting a timeout to zero indicates that the resource should be deleted. This is an example of a side-effect: the setting of a value has implications for things other than the value. In this case, it is the very existence of the resource that is affected.
That’s perfectly ok, since it’s an implementation detail, just as it’s an implementation detail that a bank account doesn’t go away if its emptied of funds. Implementation should be separate from interface.
The interface to the PUT operation is different for the timeout and the balance scenario. A client must know the inputs, outputs, and faults for the operation on either timeout or balance resources. The application gains no benefit from re-using the same operation interface. There is also a significant side-effect on one of the operations that is not shared by the other operation. WebDAV uses the term “live” to denote those properties or resources that may have operation side-effects.
No, the interface isn’t different; it’s HTTP, where 404 means not found, 200 means success, etc.. What’s different is the data, not the interface. And again, side-effects are no problem.
The use of a generic operation (which enhances intermediaries visibility into the message) does not bring any benefits because there is nothing re-usable at an intermediary, as shown in the cases of caching and security.
Wait a sec… Dave just (rightly) claimed that the generic operation improves visibility, yet later in the same sentence claims that it doesn’t provide any benefits? Which is it?
Visibility is the benefit that is provided. Perhaps it doesn’t have much value for those two examples (I believe it does, but that’s immaterial), but what about other possible uses of intermediaries that you haven’t forseen? I think it would be very short-sighted to conclude that visibility has no value based on just two examples of intermediaries.
Regarding transactions, I’d say that the scenario David describes there – of batching requests – is not an approach I would take. A general approach (though not by any means universal) that I would take would instead include a mandatory transaction identifier header in each message which was part of the same transaction. Then, in order to perform transaction-level operations, I would perhaps PUT or POST to that transaction resource as necessary. David also adds;
Combining operations that may have side-effects into transactions is potentially dangerous. An operation with a side-effect may cause errors in subsequent operations. An example is a set resource timeout to zero – which deletes the resource – followed by setting a property on the resource. The setting of the property will fail because the resource has been terminated.
Which I don’t think is the case, even if you’re batching, and in the sense of word “side-effect” used above (not in the sense used in HTTP 1.1, which is different). Again, that’s just because implementation should be separate from interface, so a client should not need to care about what happens as a result of an invocation, except as licensed by the interface; HTTP.
So I mostly agree with David’s conclusion, but I think his case could have benefitted from some better examples and a more accurate use and description of HTTP. Had he done that, I expect he would have come to the conclusion – as I have – that while there are certainly some cases where service specific state-setting operations are worth it, PUT, like GET, hits the 80/20 point.
One meta observation to wrap up… Does anybody other than me think that Dave’s interests in finding the happy spot between the Web and Web services might be better served by simply exercising the crap out of PUT (and POST) to test how general its applicability is, rather than starting from the point of view of “All Web services assumptions are valid and here’s why”?
I always appreciate it when Mark mentions me, but I’m not sure what warnings I’m heeding.
I meant those I mentioned in a my heads up to the TAG. Which, FWIW, discusses (sort-of) value in an epr URI scheme; a potential answer to your “Others?” question about how the EPR/URI mapping could occur.
Akin a legal opening argument, I intend to show that an XML based identifier systems in addition to URIs has potential upsides. These upsides will be defined in terms of the REST thesis properties.
That’ll be interesting, but keep in mind that IMO, most of the arguments against EPRs are not REST based arguments, since REST doesn’t mandate URIs. In fact, one could devise a perfectly RESTful architecture that used EPRs. No, the arguments against EPRs are the practical ones; how do you expect to deploy such a system when such a massively deployed and successful alternative – and one that could be reused – is available. I’m not sure Web service proponents really appreciate what a MASSIVE uphill battle that is. I can’t fathom an advantage that EPRs would have over URIs that would make it worthwhile.
The Architecture of the World Wide Web, First Edition indicates that distinct resources must be assigned to distinct URIs. This must be considered when refining the mechanism for the service specific message headers.
Oh, the irony (and not the Alanis kind).