For more on this topic, check out the REST Wiki.
And here's another example.
SOAP 1.1 was designed to address the needs of two very different uses. The first one that seems to be getting the most interest, is as a framework for defining new protocols and bindings that tunnel those new protocols over existing ones. This use also includes the use of RPC over application protocols such as HTTP or SMTP.
The second use is as a framework from which to extend application protocols while reusing the application semantics of those protocols (and avoiding tunneling).
The following is some definitions I'll be using in this paper.
A protocol is a contract between two parties that must be adherred to in order for its goal to be achieved.
A protocol whose goal is to implement functionality associated with the application layer in the protocol stack. HTTP, FTP, SMTP, and IMAP, are all examples of application protocols. From a user-centric point of view, basically the reason you sit down in front of your computer (to "run an app").
The SOAP envelope provides a very useful base from which to define new protocols. The distinction between protocol-metadata (or control information) and protocol-payload is commonly seen in many existing protocols today, in all layers of the protocol stack. SOAP's advantage here of course, is the use of the XML syntax, providing advantages in terms of internationalized information (via Unicode), existing and upcoming tool support (both open source and proprietary), and others.
To date, the most common kinds of protocols that are being developed are RPC based. Each new RPC interface that is defined is a new protocol (per my definition above), as the meaning of the RPC interface (methods, parameters, and return values) must be understood by both sides before its goal can be achieved, and understanding one RPC interface doesn't help you to understand other RPC interfaces.
These new protocols define their own semantics different from those of the underlying protocols they're using. The term "tunneling" is used to refer to this relationship, and care must be taken when doing it. For example, most application protocols define some kind of security model, and tunneling a new protocol over it disregards that model (as well as anything else in the protocol except its ability to move bits between endpoints).
SOAP 1.1's binding to the HTTP protocol is done in such a way that it can be used to extend HTTP, rather than (only) tunnel through it. By "extend" here, I mean that a typical use of HTTP could be extended with SOAP's XML envelope based syntax, instead of HTTP's RFC 822-based header syntax.
As an example, I may have a non-SOAP based application that I use to manage my personal contact list. It operates by providing an URL, say /user/mbaker/contacts, plus "sub URLs" for addressing invididual contacts, such as /user/mbaker/contacts/John%20Doe.
Upon the main URL, /user/mbaker/contacts, I can invoke the following methods and expect the following behaviours;
Upon the "sub URLs", I can invoke the following methods and expect the following behaviours;
Now, if I wanted to use SOAP here, my application would change in the following ways;
Two useful and valid, but very different ways of using SOAP exist, and are in use today on the Web. Understanding both is the key to knowing how to design a single binding that can be used for both uses.