Web Things, by Mark Baker

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.

“Instead, standards such as Plain Old XML (POX) over HTTP and Representational State Transfer (REST) are asserting themselves as legitimate and very credible ways of delivering on the value proposition of Web services”. Who knew?! 8-)
(link) [del.icio.us/distobj]

Tres cool demo from Microsoft, as described on Ray Ozzie’s blog;

But each site is still in many ways like a standalone application. Data inside of one site is contained within a silo. Sure, we can cut and paste text string fragments from here to there, but the excitement on the web these days is all about “structured data” such as Contacts and Profiles, Events and Calendars, and Shopping Carts and Receipts, etc. And in most cases, the structured form of this data, which could be externalized as an XML item or a microformat, generally isn’t. It’s trapped inside the page, relegated to a pretty rendering. So, where’s the clipboard of the web?

If you take a look at what gets put in your clipboard on a “copy/cut” action, you see this;

<?xml version="1.0" encoding="utf-8" ?><liveClipboard version="1.0"
xmlns:lc="http://www.microsoft.com/schemas/live"><lc:format type="hCard">
%3Cdiv%20class%3D%22vcard%22%3E%3Cdiv%20class%3D%22n%22%3E%3C
span%20class%3D%22given-name%22%3EMatt%3C/span%3E%20%3Cspan%20
class%3D%22family-name%22%3EAugustine%3C/span%3E%3C/div%3E%3Ca%20
class%3D%22email%22%20href%3D%22matta@microsoft.com%22
%3Ematta@microsoft.com%3C/a%3E%3Cdiv%20class%3D%22tel%22%3E%3C
span%20class%3D%22value%22%3E425%20707%207716%3C/span%3E
%3C/div%3E%3Cdiv%20class%3D%22adr%22%3E%3Cspan%20class%3D
%22type%22%3EWork%3C/span%3E%3A%3Cdiv%20class%3D%22street-address%22
%3E1%20Microsoft%20Way%3C/div%3E%3Cspan%20class%3D%22locality%22
%3ERedmond%3C/span%3E%20%3Cspan%20class%3D%22region%22%3EWA%3C
/span%3E%20%3Cspan%20class%3D%22postal-code%22%3E98052%3C/span
%3E%20%3Cabbr%20class%3D%22type%22%20title%3D%22dom%22%3EUSA%3C
/abbr%3E%3C/div%3E%3C/div%3E
</lc:format></liveClipboard>

I wonder what purpose is served by the proprietary XML wrapper? The “type” doesn’t need to be specified. I suppose the relevant value of the HTML profile should be imported if present, but that could also be done by prepending the relevant snippet from the HEAD, no?

Tags: microformats

Now don’t get me wrong, I do appreciate the bevy of pro – or at least neutral – REST commentary in the recent discussion. But I just can’t get excited about the “moderate” conclusions such as this from Dare Obasanjo;

If you know the target platform of the consumers of your service is going to be .NET or some other platform with rich WS-* support then you should use SOAP/WSDL/WS-*. On the other hand, if you can’t guarantee the target platform of your customers then you should build a Plain Old XML over HTTP (POX/HTTP) or REST web service.

I mean, that looks fine and dandy – as did Don’s conclusions – until you realize that the architectural properties of the resulting system aren’t a factor in the decision.

Oops! This is not progress. This is not principled design.

Tags: soap, soa, rest, webservices.

“REST folk […] appreciate schemas as much as the SOAP crowd does. We just don’t confuse the issue by putting method semantics into them.” Heh, yep.
(link) [del.icio.us/distobj]

“The Web, Plain-Old-XML, XMPP, and JSON are the way forward. And I think, deep down, everyone knows it.” If only it were so, Robert. 8-(
(link) [del.icio.us/distobj]

Don Box gives us his two cents on a Microsoft-internal “REST vs. SOA(P)” debate;

The following design decisions are orthogonal, even though people often conflate two or more of them:

1. Whether one uses SOAP or POX (plain-old-XML).
2. Whether or not one publishes an XML schema for their formats.
3. Whether or not one generates static language bindings from an XML schema.
4. The degree to which one relies on HTTP-specific features. That stated, screw with GET at your peril.
5. Whether one adopts a message-centric design approach or a resource-centric design approach.

Some of the decisions (specifically 5) are architectural and sometimes philosophical.

I don’t know about that. Numbers 1, 2, 4, and 5 are architectural, as all impact either the components, connectors, or data of the system. Only number 3 isn’t, since it’s an implementation detail. Number 2 is debateable I suppose, but most Web services based uses of XML schemas I’ve seen involves removing descriptive information from the message in deference to an implicit pointer to a WSDL document (and therefore a schema).

He also added;

If you want to reach both audiences before your competition does, you’ll avoid indulging in religious debates and ship something.

Of course, religious debates should always be avoided. But architectural debates should not, and REST vs. SOA(P) is an architectural debate. Period. If anybody thinks this is a religious debate, you simply haven’t done your homework.

Also of interest, his advice was preceded by this qualifier;

In hopes I never have to address this debate again, […]

Hah, that’s a good one 8-) Resistance is futile. You can’t fight loose coupling, man. It’s infectious. Muhaha!

Tags: soap, rest, microsoft, webservices.

How can you not want to hire Bob DuCharme when he spews gems like this; “each new XML-related technology and HTTP-capable device or platform that crops up around us adds to the combination of things that we can hook up”
(link) [del.icio.us/distobj]

Nice, thorough notes from Eve. I wonder who asked the “Do you think web services may collapse” question?
(link) [del.icio.us/distobj]

From RFC 2518 (WebDAV);

XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML’s self- describing nature allows any property’s value to be extended by adding new elements. Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and will ignore elements they do not understand.

(emphasis mine)

Hey, I wonder where it says that in the XML Rec? 8-)

See also; a presentation of mine which talks about self-descriptively extensible XML.