Comments on The View From The Bow: A Flash of Enlightenment in the SOAP vs REST Debat...

I definitely need to look more closely, but I beli...

2006-06-30T16:33:00.000-04:00

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 (http://company.com/employee_service). 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

http://company.com/employees/123

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:

<employees>
<emp_name> xlink:href="http://company.com/employees/123">John Smith</emp_name>
...
</employees>

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.

Pete

A definition for paradigm for you: A set of assum...

2006-06-30T08:17:00.000-04:00

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

I agree with Steve that REST is not a paradigm shi...

2006-06-29T20:07:00.000-04:00

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

Sorry but anyone who thinks that REST is a "paradi...

2006-06-29T18:25:00.000-04:00

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.

That's a nice management view of the argument from...

2006-06-29T17:21:00.000-04:00

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