The final thing we have to do is decide which HTTP methods will be exposed for each of our resources and what these methods will do. It is crucial that we do not assign functionality to an HTTP method that supersedes the specification-defined boundaries of that method. For example, an HTTP GET on a particular resource should be read-only. It should not change the state of the resource it is invoking on. Intermediate services like a proxy-cache, a CDN (Akamai), or your browser rely on you to follow the semantics of HTTP strictly so that they can perform built-in tasks like caching effectively. If you do not follow the definition of each HTTP method strictly, clients and administration tools cannot make assumptions about your services and your system becomes more complex.
Let’s walk through each method of our object model to determine which URIs and HTTP methods are used to represent them.
objects in our object model are all very similar in how they are
accessed and manipulated. One thing our remote clients will want to do
is to browse all the
Products in the
system. These URIs represent these objects as a group:
/orders /products /customers
To get a list of
Customers, the remote
client will call an HTTP GET on the URI of the object group it is
interested in. An example request would look like the following:
GET /products HTTP/1.1
Our service will ...