Thursday, June 29, 2006

A Flash of Enlightenment in the SOAP vs REST Debate

I just came upon this great post by Steve Jones about the pointlessness of the debate about SOAP vs REST.

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?
From that point on, tooling should just generate the endpoint middleware necessary to achieve the exchange, and infrastructure should ensure that the messages are delivered properly.

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?
After you have designed the fundamental requirements of the service, then you can expose that functionality using as many middleware technologies as you need in order to support your customers' requirements. As long as you maintain clean separation of interface from implementation, you can do that.


Jason R Briggs said...

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".

Steve Jones said...

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.

Anne Thomas Manes said...

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".

Jason R Briggs said...

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!!

Pete Lacey said...

I definitely need to look more closely, but I believe that Indigo will support REST, but not that it will allow you deploy a single unit of code and present both a RESTful and SOAPy interface.

Axis2 does indeed provide this functionality, but I'm dubious. There are two fundamental tenents to REST (mapping to HTTP assumed):

1. A limited number of verbs. GET and POST are the minimum. PUT and DELETE are nice to haves. Retrieving a resource has no side-effects.

2. Everything is a resource that's URL accessible.

Also, HTTP is to be fully leveraged.

Axis2 and (probably) Indigo seem to forget about the 2nd point and the importance of HTTP as an application protocol and not just a transport (that also has a GET).

For instance, here's a description of a simplistic "Employee" SOAP service (in pseudo-code):

service employee
- operation emp get_employee(id)
- operation emp[] get_all_employees()
- operation bool new_employee(emp)
- operation update_employee(id)
- operation delete_employee(id)

In SOAP land this is deployed to an endpoint ( And, depending on messaging style, the operation name is provided to the service.

But in the REST world an employee is mapped to a URL

So, questions:

- Is Indigo or Axis going to know how to, or allow me to, map this URL to employee.get_employee("123")?

- Are they going to map /employees to get_all_employees()?

- What if I want to map /employees to code that returns a "description" of all employees (e.g. num_employees=100, avg_salary=50000, etc.)?

- What if I want GET /employees to return a list of employee names with a link to their URL, like this:

<emp_name> xlink:href="">John Smith</emp_name>

Is that even possible?

- Will it know that a POST to /employee/123 is a call to update_employee("123)?

- If there is no employee numbered 123, will it know to call new_employee instead?

- Will it return an HTTP response code of 200 or a 201 when an employee is successfully added?

- Since both of these tools only support GET and POST right now, how will they formulate the delete call? POST /employees/123&action="delete" ?

- What if I want to inform the user-agent, web server, or proxy server about the caching characteritics of my service, can I do that?

- What if I want to switch URLs, will it return a 301?

All of the above is to say that REST is not an implementation detail.


abby brock said...

But, as I said earlier, we must accept that there are two sides of every aspect or a thing, one is good, and one is bad. Human being has not even spared Xanax, and used it as an intoxicating drug, rather abused it.

movers in virginia