Hey, it looks like Web3S was replaced by Atom/APP. Awesome. I think “Why not Atom?” was one of my first questions of Yaron when he described Web3S to me last year. I’m confident this is for the best. In addition to Atom/APP being existing standards (with an accompanying abundance of existing tooling), Microsoft will also gain the evolutionary advantages of the hypermedia as the engine of application state constraint, which Web3S opted to replace with a schema-driven application model.
Kudos to everybody involved in that decision.
David Peterson defends
SimpleDB‘s
use of HTTP GET for
mutation actions by appealing to the HTTP spec itself, specifically
pipelining where it says;
Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request.
His argument is that because POST isn’t idempotent, that it couldn’t be used for pipelining, and therefore that GET could be used. There’s two fatal flaws with this argument however. The first is that PUT is idempotent, and is also a mutator, so you can pipeline that no problem (modulo the concern about sequences of requests). The second is that if both the client and server understand that an “Action” parameter specifies the actual action to be taken (overriding the HTTP method), then if Action specifies a non-idempotent method, you’re still going to run into the same indeterminism problem that the HTTP spec warns against: what matters is the effective method of the message, not only the HTTP method.
It’s also interesting that the example Dare uses is of an Action value “PutAttributes”, which is presumably idempotent, doh!
Nope, Amazon blew it, again. I’ve offered them my services a couple times already, but they’ve not taken me up on my offer yet. They really, really(!) should before they publish another service.
Sam Ruby writes;
A much more interesting question to me is whether PATCH will operate at the content level or the transfer level. Or, to put it anther way, will patch operate at the infoset level, or will it be able to be directly applied to HTML as she is written?
PATCH means what ever the spec says it means. Anything else is a function of either the diff media type in use, or the particular implementation of the server that processes the message.
Roy Fielding joins the blogosphere. Subscribed (duh!).
Via Stefan, a proposal from the WSO2 gang for an approach to decentralizing media types and removing the requirement for the registration process.
Been there, tried that. I used to think that was a good idea, but no longer do.
Problem one: an abundance of media types is a bad thing for pretty much the same reasons that an abundance of application interfaces is a bad thing; the more that is different, the more difficult interoperability becomes. We need less, more general media types, not more specific ones.
Problem two, specific to their solution for this “problem” (which is “application/data-format;uri=http://mediatypes.example.com/foo/bar”): media type parameters don’t affect the semantics of the payload. This solution requires changing the Web to incorporate parameters in this way. Consider, if an existing firewall was configured to block, for example, image/svg+xml content. If SVG were also assigned its own “media type URI” and delivered using application/data-format, that firewall wouldn’t be able to block it. Oops.
Problem three (which mnot convinced me of): having your media type reviewed by the capable volunteers on ietf-types, is a good thing. Sure, you could still do that while using a decentralized token/process, but I consider having motivation for review built-in to the mechanism a feature, not a bug, especially given problem one above.
Update; here’s an older position of mine.