This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Resource SOAP Feed Title: Michael Lucas-Smith Feed URL: http://www.michaellucassmith.com/site.atom Feed Description: Smalltalk and my misinterpretations of life Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Michael Lucas-Smith

Here's an idea I've been persueing at work. I'm not sure what others think of it, so I'll throw it out there and see how it goes in the public realm..

Say we have a SOAP interface in to our system. We're going to bypass the WSDL for a moment and I'll explain why shortly.

The HTTP URL for a SOAP call isn't so useful, it's generally there to specify which 'container' you want to talk to. Sort of like an IP and Port number, but with an added path.

So what if we made the URL resource based - like REST is. Then the SOAP becomes an operation upon the resource you've specified.

The idea of SOAP is that all arguments to what you're doing are in the SOAP call, whether it be RPC or Document based doesn't matter so much. But this 'resource' we're talking about is another accessor entirely. I've called it 'context value'. The context is the service object initiating the SOAP call. At work I convert SOAP requests in to Smalltalk, and the Smalltalk can access the context and thus the resource being used for the soap.

Before I started doing this, every SOAP call had to include an accessor component to find the resource it was going to work on. Not only was this annoying and verbose programming, but the source of a resource can be quite varied in my system. The better way was to have a pipeline cocoon like strategy for fetching via 'generator', the resource to perform the operation on.

So! has any body else redefine the role of SOAP the way I have?