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:
~/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
waitOutput
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| 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:
- Client-server
- Stateless
- Cacheable
- Layered system
- Code on demand
- Uniform interface
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:
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>