intertwingly

It’s just data

WSDL 2.0, Encoding, and REST


Dave Orchard: For some reason Yahoo provided their documentation in text form as well as a schema for the response, they didn’t provide a WSDL 1.1 or WSDL 2.0.  I quickly wrote up the WSDL 2.0 for their service.

Looking at the provided WSDL, it wasn’t immediately obvious to me how encoding was handled.  Digging into WSDL 2.0’s definition of Serialization as “application/x-www-form-urlencoded”, I find a pointer to XFORM’s Serialization as application/x-www-form-urlencoded, which contains the following:

The encoding of EltName and value are as follows: space characters are replaced by +, and then non-ASCII and reserved characters (as defined by [RFC 2396] as amended by subsequent documents in the IETF track) are escaped by replacing the character with one or more octets of the UTF-8 representation of the character, with each octet in turn replaced by %HH, where HH represents the uppercase hexadecimal notation for the octet value and % is a literal character. Line breaks are represented as “CR LF” pairs (i.e., %0D%0A).

Works for me.

In general, I like the idea of WSDL being able to describe a larger class of operations in a non-invasive way (i.e., people are free to exploit or ignore this information).

However, unless I am missing something, I would caution against selling WSDL 2.0 as being able to model RESTful Web Services as I see no way to describe what Roy Fielding describes as distributed hypermedia.

A concrete example would be: at this endpoint, you will find a document that conforms to a given schema.  Within that document, if you find a element that matches the following xpath expression:

xhtml:link[@rel='alternate' and @type='application/rss+xml']

then the value of ./@href will contain the location of a document which is described by this schema.

If this example seems contrived, consider that it is actually typical of how one views the description of an endpoint that one might find inside a WSDL document.