SOAP, REST, RPC

 http://stackoverflow.com/questions/409338/examples-of-the-best-soap-rest-rpc-web-apis-and-why-do-you-like-them-and-what

http://geeknizer.com/rest-vs-soap-using-http-choosing-the-right-webservice-protocol/

 REST web services are:

• Lightweight – not a lot of extra xml markup
• Human Readable Results
• Easy to build – no toolkits required

SOAP also has some advantages:

• Easy to consume – sometimes
• Rigid – type checking, adheres to a contract
• Development tools

(OReilly.RESTful.Web.Services.May.2007)

SOAP
a typical SOAP service keeps its method information in the entity-body
and in a HTTP header.

Example Request Message:

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
  </soap:Header>
  <soap:Body>
    <m:GetStockPrice xmlns:m="http://www.example.org/stock">
      <m:StockName>IBM</m:StockName>
    </m:GetStockPrice>
  </soap:Body>
</soap:Envelope>

Example Response Message:

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.example.org/stock">
  <m:GetStockPriceResponse>
    <m:Price>34.5</m:Price>
  </m:GetStockPriceResponse>
</soap:Body>

</soap:Envelope> 

RESTful
In RESTful architectures, the method information goes into the HTTP method. In Resource-
Oriented Architectures, the scoping information goes into the URI. The combination
is powerful

If the HTTP method doesn't match the method information, the service isn’t RESTful. If the scoping information
isn’t in the URI, the service isn’t resource-oriented. These aren't the only requirements,
but they're good rules of thumb.

RPC
An RPC-style web service accepts an envelope full of data from its client, and sends a
similar envelope back. The method and the scoping information are kept inside the
envelope, or on stickers applied to the envelope.

Simply put, an XML-RPC service ignores most features of HTTP. It exposes
only one URI (the “endpoint”), and supports only one method on that URI (POST). e.g. No matter what you do with the UPC database service,
the URI is always http://www.upcdatabase.com/rpc and the HTTP method is always
POST.

A few well-known examples of RPC-style web services:
• All services that use XML-RPC
• Just about every SOAP service (see the “Technologies on the Programmable
Web” section later in this chapter for a defense of this controversial statement)
• A few web applications (generally poorly designed ones)

REST-RPC hybrid
The Flickr web API asks clients to use HTTP GET even when they
want to modify the data set. To delete a photo you make a GET request to a URI that
includes method=flickr.photos.delete. That’s just not what GET is for, as I’ll show in
“Split the Data Set into Resources [115]. The Flickr web API is a REST-RPC hybrid:
RESTful when the client is retrieving data through GET, RPC-style when the client is
modifying the data set.

A few well-known examples of REST-RPC hybrid services include:
• The del.icio.us API
• The “REST” Flickr web API
• Many other allegedly RESTful web services
• Most web applications