Cover by Subbu Allamaraju

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

O'Reilly logo

Chapter 1. Using the Uniform Interface

HTTP is an application-level protocol that defines operations for transferring representations between clients and servers. In this protocol, methods such as GET, POST, PUT, and DELETE are operations on resources. This protocol eliminates the need for you to invent application-specific operations such as createOrder, getStatus, updateStatus, etc. How much you can benefit from the HTTP infrastructure largely depends on how well you can use HTTP as an application-level protocol. However, a number of techniques including SOAP and some Ajax web frameworks use HTTP as a protocol to transport messages. Such usage makes poor use of HTTP-level infrastructure. This chapter presents the following recipes to highlight various aspects of using HTTP as an application protocol:

Recipe 1.1

Visibility is one of the key characteristics of HTTP. Use this recipe to learn how to maintain visibility.

Recipe 1.2

There are cases when you may need to forgo visibility to meet application needs. Use this recipe to find some scenarios.

Recipe 1.3

Use this recipe to learn the best way to manage state.

Recipe 1.4

Maintaining safety and idempotency helps servers guarantee repeatability for requests. Use this recipe when implementing servers.

Recipe 1.5

Follow this recipe to implement clients for safety and idempotency principles.

Recipe 1.6

Use this recipe to learn when to use GET.

Recipe 1.7

Use this recipe to learn when to use POST.

Recipe 1.8

Use this recipe to learn how to create new resources using the POST method.

Recipe 1.9

You can use either POST or PUT to create new resources. This recipe will discuss when using PUT is better.

Recipe 1.10

Use this recipe to learn how to use the POST method for asynchronous tasks.

Recipe 1.11

Use this recipe to learn how to use the DELETE method for asynchronous deletion of resources.

Recipe 1.12

Use this recipe to learn why custom HTTP methods are not recommended.

Recipe 1.13

Use this recipe to learn when and how to use custom HTTP headers.

1.1. How to Keep Interactions Visible

As an application protocol, HTTP is designed to keep interactions between clients and servers visible to libraries, servers, proxies, caches, and other tools. Visibility is a key characteristic of HTTP. Per Roy Fielding (see Appendix A for references), visibility is the ability of a component to monitor or mediate the interaction between two other components. When a protocol is visible, caches, proxies, firewalls, etc., can monitor and even participate in the protocol.


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.


Features like the following depend entirely on keeping requests and responses visible:


Caching responses and automatically invalidating cached responses when resources are modified

Optimistic concurrency control

Detecting concurrent writes and preventing resource changes when such operations are based on stale representations

Content negotiation

Selecting a representation among alternatives available for a given resource

Safety and idempotency

Ensuring that clients can repeat or retry certain HTTP requests

When a web service does not maintain visibility, such features will not work correctly. For instance, when the server’s usage of HTTP breaks optimistic concurrency, you may be forced to invent application-specific concurrency control mechanisms on your own.


Maintaining visibility lets you use existing HTTP software and infrastructure for features that you would otherwise have to build yourself.

HTTP achieves visibility by virtue of the following:

  • HTTP interactions are stateless. Any HTTP intermediary can infer the meaning of any given request and response without correlating them with past or future requests and responses.

  • HTTP uses a uniform interface consisting of OPTIONS, GET, HEAD, POST, PUT, DELETE, and TRACE methods. Each method in this interface operates on one and only one resource. The syntax and the meaning of each method do not change from application to application or from resource to resource. That is why HTTP is known as a uniform interface.

  • HTTP uses a MIME-like envelope format to encode representations. This format maintains a clear separation between headers and the body. Headers are visible, and except for the software that is creating the message and the software that is processing the message, every piece of software in between can treat the body as completely opaque.

Consider an HTTP request to update a resource:

# Request
PUT /movie/gone_with_the_wind HTTP/1.1 1
Host: 2
Content-Type: application/x-www-form-urlencoded

summary=...&rating=5&... 3

# Response
HTTP/1.1 200 OK 4
Content-Type: text/html;charset=UTF-8 5
Content-Length: ...


Request line containing HTTP method, path to the resource, and HTTP version


Representation headers for the request


Representation body for the request


Response status line containing HTTP version, status code, and status message


Representation headers for the response


Representation body for the response

In this example, the request is an HTTP message. The first line in this message describes the protocol and the method used by the client. The next two lines are request headers. By simply looking at these three lines, any piece of software that understands HTTP can decipher not only the intent of the request but also how to parse the body of the message. The same is the case with the response. The first line in the response indicates the version of HTTP, the status code, and a message. The next two lines tell HTTP-aware software how to interpret the message.

For RESTful web services, your key goal must be to maintain visibility to the extent possible. Keeping visibility is simple. Use each HTTP method such that it has the same semantics as specified by HTTP, and add appropriate headers to describe requests and responses.

Another part of maintaining visibility is using appropriate status codes and messages so that proxies, caches, and clients can determine the outcome of a request. A status code is an integer, and the status message is text.

As we will discuss in Recipe 1.2, there are cases where you may need to trade off visibility for other characteristics such as network efficiency, client convenience, and separation of concerns. When you make such trade-offs, carefully analyze the effect on features such as caching, idempotency, and safety.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required