I heartily concur. I will take Steve point one step further, though.
The essence of Steve argument is that the actual technologies used to implement services should not be front of mind when designing services. What should be front of mind is:
- what is the functionality that needs to be exposed?
- what are the messages that need to be exchanged to achieve that functionality?
But things are not always quite that simple -- any dependency on a specific type of middleware will constrain the reach of a service. The SOAP proponents will argue that SOAP makes XML messaging simpler and easier for people that are more familiar with the RPC-style programming model. The REST proponents argue that SOAP is too complex, and that automatic XML/object mapping is a myth, therefore the ease-of-use associated with SOAP is deceiving and misleading.
Both arguments have merit, but they are beside the point.
When you provide a service, you must cater to your customer. Therefore you must support whatever service interface your customer desires -- SOAP, REST, ebXML, "plain old XML" over HTTP, EDI, etc.
Which brings me back to Steve's basic argument. The essence of your service design must be:
- what is the functionality that needs to be exposed?
- what messages must be exchanged in order to achieve that functionality?
4 comments:
That's a nice management view of the argument from up in the boxes, but it completely misses the point of what's happening on the field.
The differences between designing REST and Soap/WS systems are nothing less than a paradigm shift in thinking. You simply cannot ignore that fact, or hide it away as an "implementation detail".
Sorry but anyone who thinks that REST is a "paradigm shift" has been drinking far too much of the Kool Aid. REST shifts bytes from A to B, SOAP shifts bytes from A to B, so does CORBA, MQSeries, RMI, DCOM, ftp, telnet, rcp, CSV to a socket or carrier pigeon. The value in the interaction is from the perspective of A and B neither of which care about how its done.
The "paradigm shift" will come when IT starts concentrating on the value of the interaction, not on building yet another way to implement the execution context.
I agree with Steve that REST is not a paradigm shift. But REST does have an impact on the interface design.
In other words, if you want to design a service that can support both RESTful and SOAPy interfaces, the service design has to be at least somewhat RESTful. But as long as you design a document-oriented, loosely coupled interface, the service should be able to support any type of interface.
And btw -- both Microsoft Windows Communication Foundation (aka "Indigo") and Apache Axis2 can automatically generate both RESTful and SOAPy interfaces for any service. These frameworks do in fact hide the type of interface as just another "implementation detail".
A definition for paradigm for you: A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality for the community that shares them, especially in an intellectual discipline.
From the simplest perspective, REST views the 'world' of as a set of resources to interact with, using a well-defined set of verbs. Assuming a uniform implementation, there are, conceivably, fewer side-effects when interacting with a resource using those semantics (e.g. a delete just deletes the resource). Note that I'm not saying no side effects, just fewer with a correct design.
Soap tends to view the 'world' as exposing API methods, RPC-like, with plenty of potential side effects. Just like accessing any other method.
So if that's not a paradigm shift, then I don't know what is.
Drinking the Kool Aid? I'm freakin bathin in it, baby!!
Post a Comment