{"id":566,"date":"2004-11-05T11:24:00","date_gmt":"2004-11-05T15:24:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/2004\/11\/05\/generic-vs-specific-state-setting\/"},"modified":"2004-11-05T11:24:00","modified_gmt":"2004-11-05T15:24:00","slug":"generic-vs-specific-state-setting","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2004\/11\/generic-vs-specific-state-setting\/","title":{"rendered":"Generic vs. specific state setting"},"content":{"rendered":"

David Orchard again tries to defend the Web services stack by\nanalyzing where service-specific state-setting operations are\nrequired. His conclusion is unsurprising;<\/p>\n\n

\nThis 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.\n<\/blockquote>\n\n

To which I would reply – modulo the choice of the word “many” there – “Of course”. But\nstill, I think the point of generic vs. specific is missed; that generic (PUT in this case)\nhits an\n80\/20 sweet spot<\/a>\n(give or take).\nThat’s all I’ve ever said, along with the comment that because it’s a sweet\nspot, it should be the starting point for the Web services architecture, and\ntherefore reified as an architectural style.<\/p>\n\n

That said, there are a few misconceptions in Dave’s post that I’d like to\naddress.<\/p>\n\n

\nThe put timeout operation has an input of the time requested, and an output of the granted timeout.\n<\/blockquote>\n\n

That would violate PUT semantics. A successful PUT response tells the\nrecipient that the state of the targetted resource was changed to the state\nreflected in the provided representation. The body of a PUT response can\nsay other things in addition to this, but nothing which violates this\ncontract, as a “granted timeout” would do. Update; actually, there\nmight be a way to do this uniformly, but I don’t think it would provide\nthe expected semantics Dave’s going for since it would require that the\ntimeout was actually set to the provided value at least for the instant\nin time that determined a successful response could be returned.<\/em><\/p>\n\n

\nSetting 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.\n<\/blockquote>\n\n

That’s perfectly ok, since it’s an implementation detail, just as it’s an\nimplementation detail that a bank account doesn’t go away if its emptied of funds.\nImplementation should be separate from interface.<\/p>\n\n

\nThe 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.\n<\/blockquote>\n\n
\nNo, the interface isn’t different; it’s HTTP, where 404 means not found,\n200 means success, etc.. What’s different is the data, not the interface.\nAnd again, side-effects are no problem.<\/p>\n<\/blockquote>\n\n
\nThe 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.\n<\/blockquote>\n\n

Wait a sec… Dave just (rightly) claimed that the generic operation improves\nvisibility, yet later in the same sentence claims that it doesn’t provide any benefits?\nWhich is it?<\/p>\n\n

Visibility is the benefit that is provided. Perhaps it doesn’t have much value for\nthose two examples (I believe it does, but that’s immaterial), but what about other\npossible uses of intermediaries that you haven’t forseen? I think it would be very\nshort-sighted to conclude that visibility has no value based on just two examples of\nintermediaries.<\/p>\n\n

Regarding transactions, I’d say that the scenario David describes there – of batching\nrequests – is not an approach I would take. A general approach (though not by any\nmeans universal) that I would take would instead include a mandatory transaction\nidentifier header in each message which was part of the same transaction. Then, in\norder to perform transaction-level operations, I would perhaps PUT or POST to that\ntransaction resource as necessary. David also adds;<\/p>\n\n

\nCombining 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.\n<\/blockquote>\n\n

Which I don’t think is the case, even if you’re batching, and in the sense of\nword “side-effect” used above (not in the\nsense used in HTTP 1.1<\/a>,\nwhich is different). Again, that’s just because implementation should be\nseparate from interface, so a client should not need to care about what happens\nas a result of an invocation, except as licensed by the interface; HTTP.<\/p>\n\n

So I mostly agree with David’s conclusion, but I think his case could have\nbenefitted from some better examples and a more accurate use and description of\nHTTP. Had he done that, I expect he would have come to the conclusion – as I\nhave – that while there are certainly some cases where service specific\nstate-setting operations are worth it, PUT, like GET, hits the 80\/20 point.<\/p>\n\n

One meta observation to wrap up… Does anybody other than me think that\nDave’s interests in finding the happy spot between the Web and Web services\nmight be better served by simply exercising the crap out of PUT (and POST) to\ntest how general its applicability is, rather than starting from the point of\nview of “All Web services assumptions are valid and here’s why”?<\/p>","protected":false},"excerpt":{"rendered":"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 […]","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-566","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/566","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/comments?post=566"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/566\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=566"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=566"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=566"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}