blog.postman.com Open in urlscan Pro
162.159.130.53  Public Scan

Form analysis
2 forms found in the DOM

GET /

<form class="form-inline my-lg-0" method="get" action="/">
  <label htmlfor="search-lc" class="search-label">
    <svg class="nav-search__icon" width="16" height="16" viewBox="0 0 16 16" fill="#6b6b6b" xmlns="http://www.w3.org/2000/svg">
      <path fill-rule="evenodd" clip-rule="evenodd"
        d="M9.87147 9.16437C10.5768 8.30243 11 7.20063 11 6C11 3.23858 8.76142 1 6 1C3.23858 1 1 3.23858 1 6C1 8.76142 3.23858 11 6 11C7.20063 11 8.30243 10.5768 9.16437 9.87147L9.89648 10.6036L9.64648 10.8536L13.5758 14.7829C13.8101 15.0172 14.19 15.0172 14.4243 14.7829L14.7829 14.4243C15.0172 14.19 15.0172 13.8101 14.7829 13.5758L10.8536 9.64648L10.6036 9.89648L9.87147 9.16437ZM6 10C8.20914 10 10 8.20914 10 6C10 3.79086 8.20914 2 6 2C3.79086 2 2 3.79086 2 6C2 8.20914 3.79086 10 6 10Z">
      </path>
    </svg>
  </label>
  <input class="form-control" id="search-lc" type="search" placeholder="Search Postman Blog" aria-label="Search" name="s" autocomplete="off" spellcheck="false" dir="auto" value="">
</form>

POST https://blog.postman.com/wp-comments-post.php?wpe-comment-post=mktgproduction

<form action="https://blog.postman.com/wp-comments-post.php?wpe-comment-post=mktgproduction" method="post" id="commentform" class="comment-form" novalidate="">
  <p class="comment-notes"><span id="email-notes">Your email address will not be published.</span> <span class="required-field-message">Required fields are marked <span class="required">*</span></span></p>
  <p class="comment-form-author"><label for="author">Your name</label><br><input class="form-control" id="author" name="author" aria-required="true"></p>
  <p class="comment-form-email"><label for="author">Your email</label><br><input class="form-control" id="email" name="email"></p>
  <p class="comment-form-comment"><label for="author">Write a public comment</label><textarea class="form-control" id="comment" name="comment" aria-required="true"></textarea></p>
</form>

Text Content

 * Product
   
   GETTING STARTED
   
   What is Postman? Customer Stories Download Postman →
   
   API PLATFORM
   
   Collaborate in Workspaces Organize with Collections Explore the API Client
   Build Postman Flows Work smarter with Postbot Browse API Tools
   
   ENTERPRISE SOLUTIONS
   
   Enterprise Essentials API Test Automation Internal API Management
 * What is Postman? API Repository Tools Governance Workspaces Integrations Get
   Started Free →
 * Pricing
 * Enterprise
 * Resources and Support
   
   LEARNING
   
   Learning Center Docs Postman Academy White Papers Breaking Changes Show
   Templates Tutorials Webinars State of the API Report Guide to API-First
   
   COMMUNITY AND EVENTS
   
   Blog Community Postman Supernovas Student Program Events Postman Swag
   
   SUPPORT
   
   Support Center Reseller Support Postman Status Release Notes Contact Us
 * Public API Network

Contact Sales Sign In Sign Up for Free Launch Postman
Blog

 * Learning Center
   
   Learn about how to get started using Postman, and read more in the product
   docs.

 * Labs
   
   Flows, gRPC, WebSockets! Learn about the latest cutting-edge features brewing
   in Postman Labs.

 * Open Technologies
   
   Invest in the knowledge, specifications, standards, tooling, data, people,
   and organizations that define the next 50 years of the API economy.

 * Collection Format
   
   Understand the specification behind Postman Collections. Check out the docs
   and support resources!

 * Blog
   
   The Postman blog is your hub for API resources, news, and community. Learn
   about the Postman API Platform and much more.


 * AI
 * API-First
 * Product Updates
 * Company News
 * Tutorials




WHAT IS CACHING?

Guest Author
November 2, 2023· 9 mins



This is a guest post written by Allen Helton, ecosystem engineer at Momento.

“It’s probably a caching issue.”

No matter how long you’ve been in the software industry, you’ve probably heard
that statement before. Next to “Did you try turning it off and on again,” it’s
one of the top excuses for random software problems. Caching is a quick and easy
scapegoat for when something that was working fine blows up all of a sudden.

They say the two hardest problems in computer science are naming things and
cache invalidation. I can personally vouch for the difficulty of both of these
things. There’s a lot to caching and none of it is particularly intuitive.


SO, WHAT IS CACHING?

Caching is a technique that involves temporarily storing data to avoid loading
it more than once. Often kept locally or in-memory, a cache prioritizes speed
over durability. Cached data is meant to be available in an instant to provide
lightning-fast performance.

By caching data, you can improve your application’s performance while reducing
network calls, database strain, and bandwidth usage. These benefits make it a
great pattern to implement.

Caching is everywhere. Server-side, client-side, browser caching, and proxy/CDN
caching are all opportunities for you to take advantage of the concept. Each
layer can temporarily store data, making your app faster no matter how it’s
used. That said, caching can also add complexity all the way down your stack.


THE ANATOMY OF HTTP CACHING

Most people associate caching with databases. They aren’t wrong; you can and
should cache database calls. But that’s not the only way you can add caching to
your app.

Remember: caching is the practice of temporarily storing data to minimize
redundant calls to your app, which includes your API.

Imagine you have a website that tracks how busy local restaurants are.
Restaurants send your website new data every 10 minutes, which includes
information like current capacity and average wait time. Your website then
serves that information to users so they can make informed decisions on where to
eat.

The website’s high-level architecture is depicted below:




SERVER-SIDE CACHING

When you receive data from restaurants, you normalize the format and save it to
your database with a lastUpdated timestamp. We know this data is only valid for
10 minutes, so we then put it into a centralized, remote cache like Momento or
Redis.

The act of saving data to a durable store like a database before saving to a
fast, temporary store is called write-aside caching. We save the data to the
cache as we write it, ensuring it’s there when we go to fetch it later.

On the flip side, we could lazily add the data to the cache. On the first fetch
of the data, we check if the data is already in the cache. If it’s not, we get
it from the database, save it to the cache, and return the data back to the
caller. The next time someone tries to load the data, it comes out of the cache
and the call to the database is skipped. This approach, which is called
read-aside caching, is used more often for larger queries or lists of data. A
write-aside cache is generally more purposeful for single item cached data.

Getting data out of the cache is only a small part of caching. We also need to
talk about a critically important and often overlooked part of HTTP caching:
HTTP headers.

Server-side code must return a certain set of headers if it expects the caller
to cache the returned data. The following headers can be used by browsers and
server-side integrations to determine caching strategies and data freshness:

 * Cache-Control: This header defines the caching policy for data and is used to
   determine cache privacy, expiration, and revalidation.
 * ETag: This header uniquely identifies the version of the data. Its value is
   typically an alphanumeric string or a timestamp.
 * Age: This header indicates how long the data returned in the response has
   been in the cache. It has a numeric value that represents the time in
   seconds.

When data is returned from the server in our example application, we should
include these headers along with the payload so callers can cache the data
appropriately:

{ 
  "headers": { 
    "Cache-Control": "max-age=600 public must-revalidate", 
    "ETag": "Wed, 10 May 2023 07:28:00 GMT", 
    "Age": 60 
  }
}

Let’s talk a bit about the values we used for our headers.

CACHE-CONTROL

The max-age=600 value of this header indicates this data will be stale after 600
seconds. Since we get a refresh of the data every 10 minutes, we set the time to
live (TTL) to 600.

We also indicated the cache data is public, which means any cache can store the
contents—even if it’s shared by multiple users like a CDN. Since our data is for
everyone, we can safely set this value. If we had restricted data, we could
provide a private directive, which indicates only the caller can cache the
value.

Lastly, we included a must-revalidate directive in our header. This means that
once the caller has cached the data for more than 600 seconds, we require them
to call the API again to refresh the data.

For a full list of Cache-Control values, click here.

ETAG

The ETag header is a unique identifier for a specific version of the data. Our
data is frequently changing, so instead of saving version numbers, we save the
timestamp from the moment the data was provided. This means that in our specific
use case, the timestamp provided in the ETag header represents unique data.

If the caller makes another request to our GET endpoint and includes this ETag,
the server code will use it to validate if there is a newer version. If the ETag
matches the current data in the database, the server will return a 304 Not
Modified response, indicating the caller already had the current version. If the
ETag does not match the server cached value, the newer version is returned with
a 200 OK status code.

AGE

Our response has an Age header with a value of 60. This header is used by the
caller to determine the data’s freshness. By returning a value of 60, we not
only indicate that the returned data was pulled out of the server cache, but
also that it had been in the cache for 60 seconds. If the data was loaded from
the database instead of the cache, we would have returned a value of 0.


CLIENT-SIDE CACHING

There tends to be some confusion around the term “client-side” when it comes to
software. Many application developers assume it refers to the user interface.
However, service developers assume it means server-side code integrating with
their service.

Both are right.

“Client-side” refers to the caller of an API, which could be a user interface or
a web service.

When it comes to caching, browser-based user interfaces get a huge benefit, as
it’s all handled automatically. Modern browsers like Chrome, Firefox, Safari,
and Edge all know of and accommodate for standard caching headers.

This means that in our restaurant app, when the browser receives the response we
just talked about, it’s going to store that data in a browser cache for 10
minutes. If a user tries to refresh the page or visits it multiple times, the
cached version will be used without sending another call to our API.

Cache headers are a little different for requests, though. Requests don’t
dictate caching strategies or inform anyone about how old the data is, so
different headers are used.

IF-NONE-MATCH

This request header contains the value provided in the ETag of a response. The
first time you load data, the ETag is returned and saved in the browser cache.
When it’s time to refresh the data, this value is provided in the If-None-Match
header, which the server uses to validate the data.

If the value provided in this header matches the server-side ETag, that means
the client already has the latest version. As mentioned earlier, the server
would return a 304 Not Modified status code and an empty response body in order
to minimize unnecessary data transfer.

If the value does not match the ETag, data is loaded from the server-side cache
and all the values we discussed earlier are returned to the caller so they can
update their end.

In our restaurant app, we’d have our cached values for 10 minutes. When the
max-age of the data is passed, our app fetches the latest from the API, being
sure to provide the last ETag we got in the If-None-Match header.

If we got data from the restaurant like we should have, the ETag wouldn’t match
and the latest data would be returned. However, if the restaurant didn’t report
data to us, the caller would already have the latest value, so it would receive
a 304 Not Modified status code and continue on its merry way.

IF-MATCH

You can also use cache data as a locking mechanism. Imagine that a restaurant in
our app let patrons manually edit the wait time (I’m not sure why they would do
that, but let’s pretend).

This functionality opens the door to potential concurrency issues, as several
people could attempt to edit the data at the same time. However, if we use the
If-Match header, our problems are solved.

Much like If-None-Match, the value of this header is the ETag returned in
response to a GET request.

In API calls that modify data, like a PUT, PATCH, or DELETE, the ETag is used to
make sure you’re modifying the latest version of the data. This prevents users
from unknowingly overwriting data that has been modified since they loaded the
page.

If you make a call with the If-Match header and the ETag does not match, the
server will return a 412 Precondition Failed response, indicating the caller
needs to reload the data before making the modification.

If the ETag does match, the operation will continue as normal.


TRY IT OUT

Caching is an advanced technique that gives applications that much-needed
performance boost, as well as stress relief during times of peak traffic. There
are many moving parts in caching, and all of them are optional. While it’s not
100% necessary to implement caching in your app before you make it to
production, it will help ensure a smooth launch.

If you want to try it out yourself, start small. You don’t have to implement
server-side and client-side caching at the same time. Generally, the easiest way
to get started is to pick your endpoints that have cacheable data and return the
caching headers. If you don’t already have your data versioned, start saving a
lastModified attribute on creation/modification so you can use it for your ETag.

How frequently does your data change? Does it update every 10 minutes like our
restaurant app? If so, set the max-age in your Cache-Control header to 600. You
don’t want your data cached longer than the average update period or you might
accidentally use a stale value.

If you’re unsure what your values should be, iterate! Start with the most
restrictive policy you can think of and start easing out from there. Software is
never finished; we’re constantly honing it and making it better. Caching is no
different. Our strategy evolves as we provide different data and understand
customer usage better. Be flexible and keep learning.

Happy coding!

+11
Tags: API 101 Caching Guest Post HTTP

Guest Author



This is a special guest author post for the Postman blog. View all posts by
Guest Author.

What do you think about this topic? Tell us in a comment below.




COMMENT CANCEL REPLY

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

Your name


Your email


Write a public comment





Δ

This site uses Akismet to reduce spam. Learn how your comment data is processed.


YOU MIGHT ALSO LIKE


WHAT ARE HTTP HEADERS?

The Postman Team· 6 mins

HTTP headers contain metadata in key-value pairs that are sent along with HTTP
requests and responses. They can be used to define…

Read more →


API DESIGN INTERVIEW QUESTIONS

Melinda Gutermuth· 15 mins

According to Postman’s 2023 State of the API report, over 75% of respondents
agree that developers at API-first companies are more productive,…

Read more →


REST VS. SOAP APIS

Guest Author· 7 mins

This is a guest post written by Chris Staudinger, co-founder and COO of
levelupcoding.co, a company that offers visual learning to simplify…

Read more →


POSTMAN NAMED BEST API PLATFORM

Postman is the #1 place where developers come to work with APIs. See why we’re
top-ranked in G2’s first-ever evaluation of API Platforms.

Read more →

© 2023 Postman, Inc.


PRODUCT

 * What is Postman?
 * API Repository
 * Tools
 * Governance
 * Workspaces
 * Integrations
 * Enterprise
 * Plans and pricing
 * Download the app
 * Support Center


COMPANY

 * About
 * Careers and culture
 * Press and media
 * Contact us
 * Partner program


LEGAL AND SECURITY

 * Terms of Service
 * Trust and Safety
 * Privacy policy
 * Cookie notice
 * Privacy choices


API CATEGORIES

 * App Security
 * Payments
 * Financial Services
 * DevOps
 * Developer Productivity
 * Data Analytics
 * Communication
 * Artifical Intelligence


SOCIAL

 * Twitter
 * LinkedIn
 * GitHub
 * YouTube
 * Asset 2
   Twitch

We use cookies on your device to enhance your navigation experience, analyze
usage to improve our site, and customize our marketing efforts. You can learn
more about cookies in ourCookie Notice.
Reject All Cookies Accept All Cookies
Manage Cookies




PRIVACY PREFERENCE CENTER

When you visit any website, it may store or retrieve information on your
browser, mostly in the form of cookies. This information might be about you,
your preferences or your device and is mostly used to make the site work as you
expect it to. The information does not usually directly identify you, but it can
give you a more personalized web experience. Because we respect your right to
privacy, you can choose not to allow some types of cookies. Click on the
different category headings to find out more and change our default settings.
However, blocking some types of cookies may impact your experience of the site
and the services we are able to offer.
More information
Allow All


MANAGE CONSENT PREFERENCES

STRICTLY NECESSARY COOKIES

Always Active

These cookies are necessary for the website to function and cannot be switched
off in our systems. They are usually only set in response to actions made by you
which amount to a request for services, such as setting your privacy
preferences, logging in or filling in forms. You can set your browser to block
or alert you about these cookies, but some parts of the site will not then work.

Cookies Details‎

FUNCTIONAL COOKIES

Functional Cookies

These cookies enable the website to provide enhanced functionality and
personalisation. They may be set by us or by third party providers whose
services we have added to our pages. If you do not allow these cookies then some
or all of these services may not function properly.

Cookies Details‎

TARGETING COOKIES

Targeting Cookies

These cookies may be set through our site by our advertising partners. They may
be used by those companies to build a profile of your interests and show you
relevant adverts on other sites. If you do not allow these cookies, you will
experience less targeted advertising.

Cookies Details‎

PERFORMANCE COOKIES

Performance Cookies

These cookies allow us to count visits and traffic sources so we can measure and
improve the performance of our site. They help us to know which pages are the
most and least popular and see how visitors move around the site. All
information these cookies collect is aggregated and therefore anonymous. If you
do not allow these cookies we will not know when you have visited our site, and
will not be able to monitor its performance.

Cookies Details‎
Back Button


COOKIE LIST



Search Icon
Filter Icon

Clear
checkbox label label
Apply Cancel
Consent Leg.Interest
checkbox label label
checkbox label label
checkbox label label

Confirm My Choices