When organizations and services expose their content using APIs, there needs to be a way for others to call and transport that content. There are two current methods for doing this - which can be characterized as 'Simple' or 'Complex'.
The easy way
The simple method is to use REST (Representational State Transfer) as the transport mechanism. REST and SOAP have a bright future together REST is a simple web-based interface that uses XML and HTTP. More than the technology behind it, REST defines itself according to a set of design principles - which proponents argue have underpinned the explosive growth and scalability of the Web. The principles can be summarized as follows:
- A stateless client/server protocol - usually means that all the information necessary to understand the request is contained in the HTTP message.
- A set of well-defined operations that apply to all pieces of information (called resources) - the main ones are GET, POST, PUT, and DELETE.
- A universal syntax for resource-identification - basically means that each resource has its own unique URI (or URL).
- The use of hypermedia both for application information and application state-transitions - using HTML and XML as the primary file type that carries the content.
There are a lot of examples of successful REST implementations on the Web. For example, an RSS feed is basically an XML file that contains lists of links to other resources. And Amazon's web services offer a REST interface, which accounts for 80% of the traffic through Amazon's APIs.
The hard way
The 'Complex' method of offering Web Services is via SOAP, which is a more abstract messaging framework - with the benefit of offering more capability and flexibility. SOAP originally stood for 'Simple Object Access Protocol', but that acronym has since been dropped.
The most common type of 'messaging pattern' in SOAP is the Remote Procedure Call (RPC), where "one network node (the client) sends a request message to another node (the server), and the server immediately sends a response message to the client." [source: Wikipedia]
Which is best?
So when it comes down to it, which Web Services approach is best: the simpler REST approach, or the more complex SOAP approach?
Someone who knows more than most what the differences are, Don from the Amazon Web Services team, wrote in a September 2005 blog entry that he hopes to see both REST and SOAP used:
"I tend to think of REST as an introduction to the world of web services, and introduction that's mostly good enough, especially for now, but one where it may need to be combined with some of the heavy weight features being built into SOAP for future applications."
Don thinks that REST and SOAP "have a bright future together", so it's worth developers keeping tabs on both.
NB: Just to clarify, I'm one of the dummies referred to in the title ;-)