Web Things, by Mark Baker

I’ve talked about both the pluses and minuses of Amazon‘s approach to Web Services for some time now. Recently, I’ve heard that they’re in the process of greatly expanding those services, which is great. But I think that before they go too far with that, they should really dig a little deeper to learn why it is exactly that their “RESTful” data retrieval services are getting the uptake they are.

I don’t think it’s controversial to claim that Amazon see the REST vs Web services debate as primarily about encodings; either a message is encoded as a SOAP envelope, or it’s encoded as a URI, but in both cases the abstract message – the information being conveyed – is identical. I completely disagree, of course, and believe that there’s a very large architectural difference between those two approaches; that in http URI form, the URI isn’t the message, and instead, the surrounding HTTP message which encapsulates that URI becomes the real message, while the URI itself is treated as an opaque bag-o-bits. Through this encapsulation, GET becomes the operation.

What I just described I refer to as “accidentally RESTful”, and it’s sur– prisingly common. And while, for the simple data retrieval case, it is RESTful, and a significant improvement over vanilla SOA, you’ll find that as you add support for state-changing actions and just generally evolve that application over time, you’re going to run into many of the same problems you’d run into doing SOA.

Fair warning!

Update; oh, I suppose this is, in part, a response to something Dare said a couple of weeks back; those APIs he lists ARE RESTful, at least with respect to using the uniform interface.