• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

REST API Tutorial

  • REST
  • JSON
  • Dark Mode
Home / REST / Caching REST API Response

Caching REST API Response

Caching is the ability to store copies of frequently accessed data in several places along the request-response path. When a consumer requests a resource representation, the request goes through a cache or a series of caches (local cache, proxy cache, or reverse proxy) toward the service hosting the resource. If any of the caches along the request path has a fresh copy of the requested representation, it uses that copy to satisfy the request. If none of the caches can satisfy the request, the request travels to the service (or origin server as it is formally known).

By using HTTP headers, an origin server indicates whether a response can be cached and, if so, by whom, and for how long. Caches along the response path can take a copy of a response, but only if the caching metadata allows them to do so.

Optimizing the network using caching improves the overall quality-of-service in the following ways:

  • Reduce bandwidth
  • Reduce latency
  • Reduce load on servers
  • Hide network failures

Caching in REST APIs

Being cacheable is one of architectural constraints of REST. GET requests should be cachable by default – until special condition arises. Usually, browsers treat all GET requests cacheable. POST requests are not cacheable by default but can be made cacheable if either an Expires header or a Cache-Control header with a directive, to explicitly allows caching, is added to the response. Responses to PUT and DELETE requests are not cacheable at all.

There are two main HTTP response headers that we can use to control caching behavior:

Expires

The Expires HTTP header specifies an absolute expiry time for a cached representation. Beyond that time, a cached representation is considered stale and must be re-validated with the origin server. To indicate that a representation never expires, a service can include a time up to one year in the future.

Expires: Fri, 20 May 2016 19:20:49 IST

Cache-Control

The header value comprises one or more comma-separated directives. These directives determine whether a response is cacheable, and if so, by whom, and for how long e.g. max-age or s-maxage directives.

Cache-Control: max-age=3600

Cacheable responses (whether to a GET or to a POST request) should also include a validator — either an ETag or a Last-Modified header.

ETag

An ETag value is an opaque string token that a server associates with a resource to uniquely identify the state of the resource over its lifetime. When the resource changes, the ETag changes accordingly.

ETag: "abcd1234567n34jv"

Last-Modified

Whereas a response’s Date header indicates when the response was generated, the Last-Modified header indicates when the associated resource last changed. The Last-Modified value cannot be less than the Date value.

Last-Modified: Fri, 10 May 2016 09:17:49 IST

Was this article helpful?

TwitterFacebookLinkedInReddit
Previous Tutorial:
REST API Security Essentials
Next Tutorial:
HATEOAS Driven REST APIs

Reader Interactions

Comments

  1. chandan says

    July 23, 2020 at 5:09 pm

    The chrome browser is not caching the “post” request’s response, even though i have the ‘Cache-Control’: ‘max-age=600’, in the response header.
    Anything else i need to do on the same? Any help is appreciated.

    Reply
    • Admin says

      July 24, 2020 at 7:28 am

      Read SO Thread

      Reply
  2. Brain2000 says

    September 9, 2019 at 4:59 pm

    If you are caching on a field level basis, and you want to update three fields of a record with a PUT request, the PUT response needs to contain the CURRENT modified date as well as the PREVIOUS modified date, using both the “Last-Modified:” and “If-Last-Modified:” headers.

    Then this logic can be applied for updating the cache:
    If the “If-Last-Modified:” date DOES NOT match the cache record’s last modified date, invalidate the record and keep only the three fields that were updated in the PUT request.
    If the “If-Last-Modified:” date DOES match the cache record’s last modified date, simply update the three fields in the cache.

    Of course, the cache’s record’s last modified date will also need to be updated using the value in the “Last-Modified:” header.

    Reply
  3. Nodon Darkeye says

    February 19, 2019 at 8:53 am

    I’m confused on the “PUT vs POST” page I read this: “PUT is idempotent, so you can cache the response.”.
    On this page under “Caching in REST APIs” I read this: “Responses to PUT and DELETE requests are not cacheable at all.”

    Feels like one of the two needs to be altered.

    Reply
    • Admin says

      February 20, 2019 at 7:01 am

      Thanks for observing and sharing it. Yes. You are right that both are contradictory statements. I have updated the text on first article.

      Reply
      • Ganijon says

        June 26, 2019 at 6:20 pm

        Looks like, you haven’t updated yet. So, PUT is idempotent, therefore its response is cache-able, right?

        Reply
        • Admin says

          June 28, 2019 at 5:36 pm

          It’s updated now. Thank You !!

          Reply
        • Kunal says

          August 2, 2019 at 1:54 pm

          Thats not true. The purpose of PUT is to update the repository (any kind) on the server side. I am not sure if there is anything to cache at all.

          Reply
          • ganesan says

            October 23, 2019 at 5:37 am

            I tend to agree, PUT for the purpose of updating something typically need not be cached by client.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Search Tutorials

Learn REST

  • What is REST?
  • REST Constraints
  • REST Resource Naming Guide

Guides

  • Caching
  • Compression
  • Content Negotiation
  • HATEOAS
  • Idempotence
  • Security Essentials
  • Versioning
  • Statelessness in REST APIs

Tech – How To

  • REST API Design Tutorial
  • Create REST APIs with JAX-RS

FAQs

  • PUT vs POST
  • N+1 Problem
  • ‘q’ Parameter

Resources

  • What is an API?
  • Comparing SOAP vs REST APIs
  • HTTP Methods
  • Richardson Maturity Model
  • HTTP Response Codes
    • 200 (OK)
    • 201 (Created)
    • 202 (Accepted)
    • 204 (No Content)
    • 301 (Moved Permanently)

Footer

References

  • The dissertation by Roy Thomas Fielding
  • Uniform Resource Identifier (URI, URL, URN) [RFC 3986]
  • Internet MediaTypes
  • Web Application Description Language (WADL)

Meta Links

  • About
  • Contact Us
  • Privacy Policy

Blogs

  • How To Do In Java

Copyright © 2020 · restfulapi.net · All Rights Reserved. | Sitemap