Today the WS-I announced a bunch of implementations of a sample application they’d speced out. Seems like a good idea.

I downloaded a couple of them, and was very pleased to see a series of URIs that appeared as though they were identifying domain objects;

http://localhost:8080/wsi/scm/logging
http://localhost:8080/wsi/scm/retailer
http://localhost:8080/wsi/scm/warehousea
http://localhost:8080/wsi/scm/warehouseb
http://localhost:8080/wsi/scm/warehousec
http://localhost:8080/wsi/scm/manufacturera
http://localhost:8080/wsi/scm/manufacturerb
http://localhost:8080/wsi/scm/manufacturerc

For a moment there, I thought my days of REST promotion were over and that secretly and collectively, WS-I members had “got it”. But alas, that wasn’t the case. Though you can invoke GET on the URIs, all they return – at least in the case of BEA’s WarehouseA URI is an HTML description of the object, include exposed operations and sample code. Bowstreet’s URI returns a SOAP fault, Sun’s returns an HTML page describing the state of the SOAP services, IBM’s returns a prophetic HTML page, and Microsoft’s returns an indication that GET isn’t supported at all. Ditto for Oracle.

So why wasn’t the returned document a description of the state of the warehouse, including inventory information? Once you’ve got the URI for a domain object (kudos on that, at least), why not serialize the state of that domain object as a response to GET requests?

Trackback

no comment until now

Add your comment now