Amazon has just announced a storage service which seems somewhat similar to Google Base (erm, apparently we can expect “Google Drive” shortly too). from a technology POV, though the business model – charging directly for storage and bandwidth consumption – is quite different.
What’s most interest here I think, is that it presents both a HTTP and SOAP (RPC) based interface. But more than that, the HTTP interface is quite rich. For one, they haven’t made the common mistake of putting operation names in URIs. For another, they’re making use of “advanced” HTTP features like caching. In fact, it appears as though the RESTful interface was developed first. How can I tell? Because many of the HTTP headers they used were simply replicated in their SOAP/XML messages. Yes, really. See for yourselves.
The HTTP GET response;
HTTP/1.1 200 OK x-amz-id-2: j5ULAWpFbJQJpukUsZ4tfXVOjVZExLtEyNTvY5feC+hHIegsN5p578JLTVpkFrpL x-amz-request-id: BE39A20848A0D52B Date: Thu, 17 Nov 2005 08:22:38 GMT x-amz-meta-family: Muntz Last-Modified: Thu, 17 Nov 2005 08:22:38 GMT ETag: "828ef3fdfa96f00ad9f27c383fc9ac7f" Content-Type: text/plain Content-Length: 5 Connection: close Server: AmazonS3 HA-HA
And the (I assume) semantically equivalent SOAP response;
<GetObjectResponse xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<GetObjectResponse>
<Status>
<Code>200</Code>
<Description>OK</Description>
</Status>
<Metadata>
<Name>Content-Type</Name>
<Value>text/plain</Value>
</Metadata>
<Metadata>
<Name>family</Name>
<Value>Muntz</Value>
</Metadata>
<Data>aGEtaGE=</Data>
<LastModified>2005-11-18T01:25:07.994Z</LastModified>
<ETag>"828ef3fdfa96f00ad9f27c383fc9ac7f"</ETag>
</GetObjectResponse>
</GetObjectResponse>
Ouch! I honestly don’t know where to start.
But what was wrong with simply supporting RESTful SOAP, and returning the data wrapped in a SOAP envelope, adorned with (essentially) the same HTTP metadata as in the pure HTTP example above? It would be returned if the HTTP request included a “Accept: application/soap+xml” header. That way you get to save face by telling folks you support SOAP, while also getting all the benefits of reusing the Web. *shrug*
I find it hard to believe that the bright folks at Amazon did this because they felt it was useful. I imagine there must have been a mandate that came down from up high dictating “All services must expose SOAP and REST interfaces”. Because that SOAP interface is comical. Nevermind 85%/15%, I’d be surprised if anybody used it.
William Henry wrote a little piece called Poor Service Semantics where he criticizes uses of CORBA IDL that offer operations like “runIt” or “doIt”. He writes;
The problem with these is that the semantics are lost as to what the business actually is doing.
Rubbish! “what the business actually is doing” is determined by the implementation of the service. Do you want clients of your services to have dependencies upon those implementations? I thought not. We have a name for that practice, “tight coupling”.
submitPizzaOrder() tells you less about what the business is doing than submitPepperoniPizzaOrder(), but is it somehow less of business semantic as a result? No, of course not, it’s just more general. Likewise, submitOrder() is more general still, and submit() yet more general again … so general in fact that it can’t be generalized any further (i.e. it’s uniform).
doIt, runIt, submit, processMessage, or POST; whatever you want to call your “process this document” semantic, it’s most definitely a business operation, just a highly reusable one.
Tags: soa, rest, mest, webservices.