As you might already know, HTTP specifications have a set of standard headers, through which a client can get information about a requested resource, and carry the messages that indicate its representations and may serve as directives to control intermediary caches.

The following points suggest a few sets of rules conforming to the HTTP standard headers:

• Should use content-type: Client and servers rely on this header to indicate how to process the message's body, as the value of the content-type specifies the form of the data contained in the request or response message body called media types.
• Should use content-length: The client should know the size of the message body that it is about to read. The other benefit is that the client gets to know how large the response body is that it needs to download, without needing to download the whole response by making a HEAD request.
• Should use last-modified in responses: The response should specify the timestamp when the representational state of the required resource was modified or updated so that the client and cache intermediaries can rely on this header to determine the freshness of their local copies of a resource's state representation. The last-modified header should be part of their requests.
• Should use ETag in responses: Entity tag (ETag) is an HTTP header that helps the client to identify a specific version of the resources they asked for. The server should always respond with the ETag as a header for the client GET requests. The value of the ETag is commonly a digest (hash value, for instance, MD5 hash) of the resource contents so that the server can identify whether the cached contents of the resources are different from the latest version of the resources. ETag differs from the last-modified header by the value (resource content as digest versus timestamp). This header value enables the client to choose whether or not to send the representation again by using If-Non-Match conditionals in the future GET requests. If the ETag value hasn't changed, then the client can decide to save time and bandwidth by not sending the representation again in their subsequent GET requests.
• Stores must support conditional PUT requests: REST API can support conditional PUT requests by relying on client requests with If-Unmodified-Since, and/or If-Match request headers. As the store resources use the PUT method for both inserts and updates, the REST API should know the client's intent of the PUT requests. PUT is the same as POST except PUT is *idempotent. Please note that HTTP supports conditional requests with the GET, POST , and DELETE methods; this is an essential pattern for allowing writable REST APIs to help collaboration among API clients.

• Should use the location to specify the URI of newly created resources (through PUT): In response to the successful creation of resources through collections or stores, the API should provide the location (URI) of the newly created resource as a response header. The location header can be part of the status code 202 response to direct the clients about the status of their asynchronous call.
• Should leverage HTTP cache headers: This is to encourage caching, provide cache-control, Expires, and date-response headers to leverage caching at various levels, such as the API server side, content delivery networks (CDN), or even at the client's network. Some examples are as follows:
  •  Cache-Control: max-age=90, must-revalidate (max-age is in seconds)
  • For HTTP 1.0 based caches,Date: Tue, 29 Apr 2018 08:12:31 GMTExpires: Fri, 04 May 2018 16:00:00 GMT

To discourage caching, add cache-control headers with no-cache and no-store, with the following:

• • For HTTP 1.0 legacy caches
  • Add the Pragma—no-cache and Expires—0 header values

However, unless necessary, REST API should always provoke caching of responses, maybe by shorter duration instead of using a no-cache directive. So the clients get faster responses for frequent access requests by fetching the short-lived response copies.

• Should use expiration headers with 200 ("OK") responses: Setting expiration caching headers in response to the successful GET and HEAD requests encourages caching at the client side. Please note that the POST method is also cacheable, and so don't treat this method as non-cacheable.
• May use expiration caching headers with 3xx and 4xx responses: In addition to status code 200 ("OK": successful responses), the APIs can include caching headers for 3xx and 4xx responses, also known as negative caching. It helps the REST API server with a reduction in loads due to some redirection and error triggers.
• Mustn't use custom HTTP headers: The primary purpose of custom HTTP headers is to provide additional information and troubleshooting tips for app developers; however, for some distinctive cases at the server side, it comes in handy unless those cases do not change the behavior of the HTTP methods. An example could be an API that makes use of the X-cache header to let app developers know whether the resource is delivered by the origin server or by the edge server. If the information that should go through a custom HTTP header is critical in that it needs an accurate interpretation of the request or response, then it is better for it to be included in the body of the request or response or in the URI used for that request.