Web Things, by Mark Baker

I think Jorgen misses part of the point of the team comment for WS-Transfer, when he writes;

The W3C Staff comments on WS-Transfer make interesting reading – and really summarize what WS-Transfer is all about: […] WS-Transfer does not have all the features of HTTP regarding the manipulation of representations, such as caching, or content and language negotiation. However, the extensibility of SOAP would allow to add such capabilities incrementally, and it can benefit from the use of existing SOAP extensions such as WS-Security for security, or WS-Reliability or WS-Reliable Messaging for reliability.

How can it be a good thing, that all those features were lost and replaced with … wait for it … merely the opportunity to add them back in the future?! Do these folks realize the amount of money that’s been spent optimizing and deploying the Web, CDNs, and caching infrastructure in general? You think people are eager to redeploy all that? And for what, angle brackets?

Egads. Whether you believe in my position on Web services or not, hopefully you can at least appreciate that reuse and not reinvention is in everybody’s best interest. The authors of WS-Transfer clearly don’t. There’s even better ways to use SOAP for data transfer, ferchrisakes!

I’m calling bullshit on WS-Transfer. Please join me.

P.S. here’s some previous thoughts on this mess, before the W3C submission, when I was obviously in a much more agreeable mood. I guess I’m pissed off at the W3C for missing yet another opportunity to set these wayward soles straight.

Update; Thanks, Simon. Go, Mark. Even Rob can’t help himself. Kudos, Stefan.

Tags: soap, rest, web, webservices.

I was just about to blog about this, when I noticed Lucas already did it for me…
(link) [del.icio.us/distobj]

“I wonder if the editors have any more sense of how wrong this is than the authors?” Indeed, it seems like critical thinking and principled design has been sacrificed at the altar of SOA. Check your brains at the door, please!
(link) [del.icio.us/distobj]

If Rob was right, then this spec can only be an attempt by Microsoft to get the other co-submitters to implement and deploy a protocol which is vastly inferior to HTTP.

Sounds too insidious to me. I think it’s just bad design.

Hmm, March 15. Me thinks this was published a couple of weeks early. This is not progress. It’s reinventing (very poorly) a perfectly good and pervasively deployed wheel. Sigh.
(link) [del.icio.us/distobj]

Congrats to James. I can honestly say that I’m not the least bit envious. 8-)
(link) [del.icio.us/distobj]

Topic: RESTful PHP. Looks nice.
(link) [del.icio.us/distobj]

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>&quot;828ef3fdfa96f00ad9f27c383fc9ac7f&quot;</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.

“My first goal with this plugin is to attempt to try to show how much HTTP kicks ass”. A plugin to make Rails more RESTful.
(link) [del.icio.us/distobj]

“Our approach is based on the REST architectural style and emphasizes abstraction of data and services as resources, interoperation via self describing data and service orchestration with loosely typed components”
(link) [del.icio.us/distobj]