[Wsf-general] Data service REST interface

[James Clark]

I think the data service configuration file should enable WSAS to
provide a REST interface as well as an SOA-style interface. The extent
to which the WSDL HTTP binding can provide an interface which is
semantically RESTful is very limited, because the needed semantic
information is not available. However, the data service can be much
more semantically aware, so there's the potential areto provide deep
REST support.

I don't know how much everybody knows about REST, but here's a nice
introductory article:

http://www.xml.com/pub/a/2004/12/01/restful-web.html

If we take the orders database I gave in my previous message, here are
some examples of the sort of things I would expect from a decent REST
interface.

To add a customer, I might POST the following to
http://example.com/customers:

<customer>
<name>John Smith</name>
<birthDate>1942-01-01</birthDate>
<phoneNumber>111-222-3333</phoneNumber>
<country>US</country>
</customer>

The server would then reply giving the URI for the customer that added:

HTTP/1.1 201 Created
Location: http://example.com/customers/1234

If I wanted to get information about a particular customer, I would do a
GET on the URI for that customer. Thus GET on
http://example.com/customters/1234 might return:

<customer>
<uri>http://example.com/customers/1234</uri>
<name>John Smith</name>
<birthDate>1942-01-01</birthDate>
<phoneNumber>111-222-3333</phoneNumber>
<country>US</country>
</customer>

If I wanted to change, say, the phone number, I would do a PUT with the
new info:

<customer>
<uri>http://example.com/customers/1234</uri>
<name>John Smith</name>
<birthDate>1942-01-01</birthDate>
<phoneNumber>444-555-6666</phoneNumber>
<country>US</country>
</customer>

To find customers in the US, I might do a GET on
http://example.com/customers?country=US and get back:

<customers>
<customer>
<uri>http://example.com/customers/1234</uri>
<name>John Smith</name>
</customer>
<customer>
<uri>http://example.com/customers/1235</uri>
<name>Fred Jones</name>
</customer>
</customers>

(i.e. it's returning a URI, plus a subset of the complete information
about the customer).

There should also be ETag support to protect against conflicting
updates.

As an alternative to/in addition to doing a straight REST interface like
this, we could use Atom and the Atom Publishing Protocol to provide the
interface. See

http://www.ietf.org/html.charters/atompub-charter.html

This might be a bit easier to support in that it's a little more
constrained than arbitrary REST.

James