According to Mark Baker most developers (85% vs 15%) will use the HTTP-based mechanisms for accessing the Amazon S3 service. This is because the “SOAP interface is comical”. I won’t try to support Amazon‘s design. That’s their job. I would like to make a comment from a developer’s point of view.
As much as I dislike WSDL because of its use of the ‘interface’ and ‘operation’ abstractions, it still represents a technology in the Web Services metadata space which doesn’t have a widely accepted and well supported equivalent in the HTTP-as-application-protocol world yet. I just tried WCF‘s WSDL-to-code generation utility against the Amazon S3 WSDL (“svcutil http://s3.amazonaws.com/doc/2006-03-01/AmazonS3.wsdl”) and voila, I have code to help me start. Granted, it gives me an object-oriented interface which I dislike rather than a message-oriented one but the point is that I used a declarative description of the service as a tool to bootstrap my interaction. Now, when we start using WS-Policy and messaging-behaviour descriptions like SSDL the sky is the limit 🙂
Don’t get me wrong, I am not arguing against the HTTP-based mechanisms. Obviously we need both. I just missed the blogosphere discussions 🙂
3 responses to “Amazon S3 – HTTP or Web Services: which is easier to use?”
I wonder how much of the wierdness in the SOAP API is a result of trying to get one code stack to support both interfaces. It looks like they built an HTTP-based implementation first, and then just defined a mapping from the HTTP information set into the SOAP infoset.
Indeed, it seems that they did exactly that. The SOAP messages seem to be an afterthought, just a wrapper against their existing HTTP-based implementation.
That’s what I concluded too, although you’ll also notice their HTTP-equivalent headers didn’t make it into SOAP headers, but into some other envelope format of their own creation.
BTW, I said I doubt *anybody* would use this SOAP interface, unlike their other APIs which is where the 85/15 numbers came from.