REST versus SOAP for XML APIs

REST (Roy Fielding's 2000 dissertation) treats data as resources with URLs, acted on by HTTP's methods, status codes and headers; there is no envelope, and Accept chooses the format:

rest.sh: the same price as a resource, in XML and JSONShell
~/de-venv/bin/python -c 'import server, time; server.start(); time.sleep(4)' &
sleep 2
curl -si localhost:31081/books/BN-0003 | tr -d '\r' | grep -E '^HTTP|^Content|<title|<price'
curl -s -H 'Accept: application/json' localhost:31081/books/BN-0003; echo
curl -s -o /dev/null -w '%{http_code}\n' localhost:31081/books/BN-9999
wait
Output
HTTP/1.0 200 OK
Content-Type: application/xml
    <title>Salt and Saffron</title>
      <price currency="USD">24.00</price>
{"sku": "BN-0003", "price": "24.00"}
404
SOAP and REST compared
Aspect SOAP REST over HTTP
Contract WSDL with XSD, required OpenAPI, optional
Transport use POST to one endpoint GET, PUT, DELETE on resources
Errors Fault in the body, HTTP 500 HTTP status codes
Formats XML only XML, JSON, anything

REST is easier to page and cache; SOAP's strict contract is easier to validate.


REST

Representational State Transfer (REST) is an abstraction of the World Wide Web.

A web service is "RESTful" if it conforms to the following constraints:

Whereas SOAP is a protocol, REST is an architectural style. As such, there is no "official" standard for RESTful web APIs. Nevertheless, a RESTful implementation such as the Web can use standards like HTTP 30 , URI 30 , XML 30 , etc.

Under the uniform interface constraint, resources are identified by URIs, and standard HTTP methods (GET, POST, PUT, DELETE) act on those resources. A GET request against a resource's URI, for example, can return an XML representation of that resource:
ch10-rest-example.http
Request:

GET /books/123321 HTTP/1.1
Host: api.example.com
Accept: application/xml

Response:

HTTP/1.1 200 OK
Content-Type: application/xml

<book id="123321">
   <title>Harry Potter</title>
   <author>J. K. Rowling</author>
   <price>22.90</price>
</book>