Most developers equate Web services with SOAP, the Simple Object Access Protocol. SOAP is a new protocol that builds an RPC layer over HTTP and XML. There is little doubt that Web services will use HTTP and XML, but not everybody agrees that SOAP is the ideal implementation.
An RPC-Based Solution
SOAP draws largely from RPC and object-oriented middlewares such as DCOM (Microsoft), RMI, (Sun) or CORBA (vendor neutral). The appeal of SOAP is that it is mostly transparent to developers. Its object model makes it an easy match for Java, C++, C#, and other object-oriented languages. Language binding in the .Net runtime, or through Java XML-RPC, takes care of the protocol drudgeries.
As an example of Web services, look at the Google API. Google offers a SOAP interface over its popular search engine. Applications query Google and can integrate search results within their site. Details of the API are at www.google.com/apis.
SOAP has powerful sponsors (Microsoft, IBM, and now Sun) and enjoys a growing awareness in the developer community. Still, not everybody is convinced. One of the most vocal arguments centers on the REST (REpresentational State Transfer) architectural style.
Unlike SOAP, REST is not a protocol. It’s more a philosophy on how to design and develop distributed systems. The term was coined by Roy Fielding, in his PhD thesis, as he tried to formalize the Web, the largest distributed application ever, and learn a few lessons on distributed application architecture in the process.
A Fundamental Difference
Historically, RPC has been most successful in closed projects where clients and servers are developed conjointly. RPC-inspired protocols give server developers lots of flexibility in specifying the interface. Any object or method can be made available remotely. With this flexibility comes a need for coordination that does not bode well with openly accessible servers.
In contrast, the Web has a simplistic interface with only four main methods (GET, POST, PUT, and DELETE—the later two are seldom available for security reasons). The scalability of the Web comes from its addressing scheme, the URIs, because URIs can point to any resource. Therefore, the relatively few HTTP verbs can be applied to any data.
What it means in practice is that given an URI (for example, http://www.marchal.com), you can try any of the HTTP verbs: access the data (GET), insert new data (POST), send a new document (PUT), or erase it (DELETE). The server may refuse some of the requests (for example, DELETE) but, and this is crucial, it understands them all.
For an example of a Web services that conforms to the REST architecture style, look at the Amazon.com associates API (available at associates.amazon.com). It lets an associate query the Amazon.com database and integrate the search results in their site. The query is a regular HTTP GET and the result is an XML document.
REST proponents advocate a “back to Web basics” approach for Web services. Whether it will scale better than SOAP, nobody knows. Both SOAP and REST try to take working technology (respectively RPC and HTTP) into new territories (Web services).
Still, there’s an important lesson to developers: Design for maximum flexibility because Web services remain a moving target.
About the Author
Benoît Marchal is a Belgian developer and writer. He is the author of XML by Example (two editions), Applied XML Solutions, and a columnist for developerWorks. There’s more on this topic at marchal.com.