Caching responses

The response caching code introduced earlier in this chapter can be applied to almost all HTTP requests, but we only used it for HTTP GET. Of the many different types of HTTP requests, only three are deemed to be cacheable (GET, HEAD, and POST), and the HEAD request doesn't return a body and so isn't useful in our application. The POST method is indicative of an action being performed, so in our context (and most others), it's more important to know that it completed, rather than to save the response it caused (see the Queuing actions section next). To learn more about the types of HTTP requests, see https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol.

In addition to this, it may not be suitable to cache the response to every GET request. While HTTP is a stateless protocol, the server that you're communicating with may be tracking state that could affect the response to your request. If your application knows that the response to a request will be time sensitive, you could make sure that it skips the cache or set a timeout on that cache entry. Unfortunately, it may not always be possible to know this in advance; this is where HTTP headers (and the HEAD method) can be helpful. By examining the headers of a response, you may see Last-Modified or ETag metadata (by issuing a HEAD request, you can access this information without the full response data being sent). If the Last-Modified header contains a time that's earlier than the creation of your cache entry, then your cache can still be used, otherwise you should remove the cached item and replace it with a fresh request. Using ETag is usually more efficient as it doesn't require any date parsing, but you'll need to store the appropriate tag for each cached response. This metadata is used as a unique identity for the response content and, if the data were to be changed in any way, the ETag would change as well (at which point you would reset the cache, as mentioned earlier).

If implementing a complete HTTP cache, there are other headers to be aware of as well, most notably Cache-Control. If this value is set to no-cache or no-store (or a combination including those values), the server is indicating that the response must never be cached. This is probably an indication that the content is specific to that request and the time of request, or that there's another reason that issuing the same request again would return a different response body.

With all of these considerations properly addressed, the code to manage a response cache is a lot more complicated than illustrated earlier in this chapter, which is why various Go packages exist to manage the details. Searching in your favorite search engine for golang http cache will probably return the most popular results.