« Google Sitemaps | Main | Open Source's Place in the Sun »
Some Thoughts about Building InfoCard on REST
Kim Cameron has a very cogent piece on WS-Policy. In fact, read it and forget the standard. Everything you need to know is in Kim’s description. This was timely because I’ve been considering my article at Between the Lines on a RESTful alternative (or augmentation perhaps) to the InfoCard proposal, something that was sparked by some questions from Doc. As I read Kim’s description, I realized that there really no need to redo WS-Policy for REST—it can be used as is.
One way to think about the RESTian argument is to separate out those parts of the WS stack that are about transport and those that are not. SOAP, WSDL, UDDI, WS-MEX, WS-ReliableMessaging, and so on are about defining transport for XML documents. This is especially apparent when you consider the Doc Literal style of using SOAP. The goal is to define an HTTP-independent way of transporting XML documents around in order to define services. The other standards are ways of declaring meta information about the service.
The REST folks argue “why replace HTTP?” Just forget SOAP and use HTTP instead. There’s some real meat to this argument. In particular, RESTful services seem to be easier to use. My point, however, is not to convince you to use REST or SOAP, but to convince you that these are just two different ways of transporting XML documents around.
What the RESTians have not done, however, is to define solutions to the very problems that most of the WS-* stack addresses. I believe we need to come up with equivalent alternatives in the REST world for things like WS-MEX or WSDL—all the transport related stuff. We don’t, however, need to replace the XML documents and the security and policy declarations that accompany them.
Things like WS-Policy and WS-Security could just as easily be used with RESTful services as they could with SOAP-based services. Sure, we’d need some conventions to pass the reference for the declaration in the message header so that it accompanies the XML document and maybe a few other things, but I think it’s workable. If you read through Kim’s description of WS-Policy, you’ll see that the issues it solves and the ways it does so would work very well in a RESTful service.
Posted by windley on June 8, 2005 1:27 PM
Comment from Dion Hinchcliffe at June 9, 2005 8:38 AM
Right on Phil,
I think the WS-* stack is a wonderful thing for those folks that have tools that can support it. But it's certainly overkill for so many applications.
REST is just a terrific solution for a good number of problem spaces. But as you point out, it would be great if there was an elegant way to "port" some of the nicer pieces of WS-* into REST when you need it.
Along this line, I've been tracking on my blog some alternative ways of getting a description language (like WSDL) working for REST and other web service styles since service description is the first problem you encounter in the non-WS-* arena.
Where will it all go? Your guess is as good as mine but if no standards are created, it's inevitable that ad hoc methods will emerge, as they have already with new service description languages like WRDL, RSWS, SMEX-D, etc.
Comment from Stefan Tilkov at June 9, 2005 1:39 PM
SOAP can be used in perfectly RESTful scenarios, and both UDDI and SOAP have got nothing to do with transport. It would be an interesting exercise to take a look at the WS-* standards and assess their applicability in a REST scenario ...
Comment from Johannes Ernst at June 9, 2005 9:45 PM
Phil Windley asks if InfoCard could be used with REST. To my surprise, more than a day after he posted it, according to Technorati, nobody has blogged back yet except for two brief comments on his site. So let me try to ponder his very good question ... As I see it, it actually expands into three related questions ... more at http://netmesh.info/jernst/Digital_Identity/phil-windley-infocard-rest.html
Comment from Phil Windley at June 10, 2005 8:20 AM
I think we're disagreeing on too fine a point Stefan. When I say SOAP is about transport, I don't mean its the actual transport mechanism. However, it's purpose is to create another layer of indirection on top of other transport layers and move XML documents around. In that sense, it's just abstracted transport.