You want to know what visibility means and what you can do to keep HTTP requests and responses visible.

Once you identify and design resources, use GET to get a representation of a resource, PUT to update a resource, DELETE to delete a resource, and POST to perform a variety of potentially nonidempotent and unsafe operations. Add appropriate HTTP headers to describe requests and responses.

You want to know common situations that may require you to keep requests and responses less visible to the protocol.

Whenever you have multiple resources that share data or whenever an operation modifies more than one resource, be prepared to trade visibility for better abstraction of information, loose coupling, network efficiency, resource granularity, or pure client convenience.

You want to know how to manage state in RESTful web services such that you do not need to rely on in-memory sessions on servers.

Encode application state into URIs, and include those URIs into representations via links (see Chapter 5). Let clients use these URIs to interact with resources. If the state is large or cannot be transported to clients for security or privacy reasons, store the application state in a durable storage (such as a database or a filesystem), and encode a reference to that state in URIs.

You want to know what idempotency and safety mean, and what you can do to ensure that the server’s implementation of various HTTP methods maintain these two characteristics.

While implementing GET, OPTIONS, and HEAD methods, do not cause any side effects. When a client resubmits a GET, HEAD, OPTIONS, PUT, orDELETE request, ensure that the server provides the same response except under concurrent conditions (see Chapter 10).

You want to know how to implement HTTP requests that are idempotent and/or safe.

Treat GET, OPTIONS, and HEAD as read-only operations, and send those requests whenever required.

In the case of network or software failures, resubmit GET, PUT, and DELETE requests to confirm, supplying If-Unmodified-Since and/or If-Match conditional headers (see Chapter 10).

Do not repeat POST requests, unless the client knows ahead of time (e.g., via server’s documentation) that its implementation of POST for any particular resource is idempotent.