To go into further detail, it's important to understand the difference between how REST and SOAP/WSDL are implemented and used. REST identifies a single resource with a URI. I'll use the example of http://www/service/person?id=123 to identify the person of ID 123. The web service might then support the operations GET, PUT, POST, and DELETE which correspond to the four actions you can perform on a person. GET requests would return some XML like

<person>

  <id>123</id>

  <name>Wesley Miaw</name>

  <sex>male</sex>

  <age>27</age>

</person>

With REST there is nothing to define exactly what is okay and what is not okay for the request body XML. I could put something completely different for the value of sex and there's nothing on the client side that says that value is illegal. There's also nothing that would prevent me from putting some random junk into the request body. The only way I can know if I sent the wrong kind of content from the client is to get an error response back from the server. That's why I consider REST to be similar to an interpreted, loosely typed, scripting language.

In contrast, the WSDL for a SOAP web service would specify exactly what types of values can be specified, and it would be a client side error to try and put a string type into a parameter that the WSDL defines as an integer. Any client side implementation that conforms to the WSDL would be able to enforce this restriction without requiring support for arbitrary errors in the server response. So now, the server only needs to return errors that have meaning at the application layer, rather than at the language layer. For example, will be errors for trying to update a non-existent person or if the client is not authorized to perform the transaction, but no errors for trying to shove an integer into a string.

There is something akin to WSDL which some people are using for REST, called WADL. WADL does enforce types, which is good, and it also defines the interface and supported HTTP methods. There are also WADL code generators.

With WADL, REST gets back type safety, but it still doesn't get back all of the flexibility of SOAP since you're still restricted to HTTP methods (unless you make the URI specify the method, which is not how REST is defined or how WADL describes the service) and you are still working with the idea of resources or objects instead of actions or commands. Plus, you are still closely tied to the actual communication protocol, HTTP. The REST versus RPC section on Wikipedia describes the restrictions of REST pretty well.

In comparison, with SOAP I might define a PersonService that has methods like void setAge(int) or Car getCar() to change a person's age or find out what kind of car he drives. A REST implementation would require a new URI specifically for a person's age and to access a person's car, for this level of granularity. The URI to a Car URI might be found in the returned Person object.

Of course, REST does have some significant advantages over SOAP.

1. It's much easier to understand what is travelling over the wire, because a resource is a URI and the different HTTP methods are the actions.


2. It sends less data over the wire than a SOAP message, because SOAP includes an envelope that wraps the actual data.


3. Tighter coupling between web server infrastructure and the web service. You basically can get for free any of the things you take advantage of with regular web servers, like caching and access logs and simple web browser clients.

As a side, Apache CXF does support RESTful services, but does not support code generation from a WADL. The older XFire implementation does not support REST in any form.

Post a comment