Just in case this useful table disappears from Classification of HTTP-based APIs, I've copied it here:
| Name | Description | Typical Signs | REST Interface Constraints | Example | |||
|---|---|---|---|---|---|---|---|
| Identification of resources | Manipulation of resources through representations | Self-descriptive messages | Hypermedia as the engine of application state | ||||
| Web Services | SOAP | IDL (WSDL) describes interface, HTTP treated as transport. | No—only service endpoint is identified by URI. No resources exposed. | No—SOAP body contains operation name; message not transferred to manipulate resource state. | No—message semantics depend on action specified in message body. | No—Application state machine known at design time. |
•flickr
SOAP API •Google AdSense API |
| RPC | Remote procedure call/URI-tunneling. APIs expose resources but operations are tunneled through action parameters in URIs. | Design time descripton of URI space, typed resources, API-specific
operations, action parameters specify operation, application specific
failure codes. Dangerous variant: tunneling unsafe operations ('delete account') through safe method (GET) No use of WADL. |
OK | No - URI contains action; message not transferred to manipulate resource state. | No - message semantics depend on action specified in URI | No - URI space and application state machine known at design time. | •Amazon SimpleDB •flickr 'REST' API |
| HTTP-based Type I | Resources are exposed, HTTP methods used correctly, use of generic media types (e.g. application/xml) | Design time descripton of URI space, typed resources, design time WADL
(description of available resources,methods and representations), API
describes schema for generic media type(s) used, operations are translated
to client-side OO-API, for example
Order order = new Order("http://foo/orders/1);
order.ship();
|
OK | OK | No - message semantics implied by specific schema used is only known to client and server but not intermediaries. | No - application state machine is known at design time. Assumptions about available representations and transitions are hard-coded (or configured). Client and server are coupled by original design. | •Twitter API |
| HTTP-based Type II | Resources are exposed, HTTP methods used correctly, use of specific media types (e.g. application/atomsvc+xml) | Design time descripton of URI space, typed resources, design time WADL
(description of available resources,methods and representations), API
description lists specific media types and for which resources they are
used, operations are translated to client-side OO-API, for example
Order order = new Order("http://foo/orders/1);
order.ship();
|
Ok | Ok | Ok | No - application state machine is known at design time. Assumptions about available representations and transitions are hard-coded (or configured). Client and server are coupled by original design. | •Google Calendar API |
| REST | Adherence to all REST constraints | All service description comes in the form of media type (and link relation etc.) specifications, client only knows entry bookmark (URI) and media types and no specifics about the particular service. Client proceeds through application by looking at one response at a time, each time evaluating how best to proceed given its overall goal and the available transitions. Methods to use are known from media type (and link relation etc.) specifications or selected at runtime based on forms (form semantics known from media type specifications). | Ok | Ok | Ok | Ok |
•Atom Publishing Protocol
(RFC 5023) •OpenSearch •Infoweb.net •RESTifying Procurement |