httpcache provides the
HTTP verb functions
DELETE, which are drop-in
replacements for those in the httr package. So, to take advantage of these cache-aware functions, all you need to do is load
httpcache instead of
httr, or in package development, import from
system.time(a <- GET("http://httpbin.org/get"))
## user system elapsed ## 0.013 0.004 0.319
system.time(b <- GET("http://httpbin.org/get"))
## user system elapsed ## 0 0 0
Notice how the second request returns instantly. It's reading from cache–there's no communication with a remote server, so no network latency and no server processing time. Remember: the fastest API request is the one you don't have to make.
Reading from the query cache yields exactly the same response as if we had contacted the server. We can confirm:
##  TRUE
How do we know, other than by the faster response, that we're hitting cache and not making server requests?
When designing API clients in R, logging is an invaluable tool for understanding and improving request patterns. As you build layers of abstraction on top of the direct HTTP requests, it can be easy to make inefficient or repetitive requests that degrade performance for your users and impose unnecessary load on your servers. You can't improve what you can't measure, and the logging tools included in
httpcache can help you measure.
Let's clear the cache and repeat that exercise, this time with logging enabled. Use
startLog to enable the request log.
startLog takes a file or connection argument, which it passes to
cat for log writing. The default, same as for
cat, prints to the standard output–your display, in an interactive session. (See
?cat for details.)
clearCache() startLog() a <- GET("http://httpbin.org/get")
## 2016-08-29T10:29:41.820 HTTP GET http://httpbin.org/get 200 0.086839 ## 2016-08-29T10:29:41.821 CACHE SET http://httpbin.org/get
b <- GET("http://httpbin.org/get")
## 2016-08-29T10:29:41.823 CACHE HIT http://httpbin.org/get
Notice how the first request results in an “HTTP GET” and a “CACHE SET”, while the second one gets a “CACHE HIT” and does not touch “HTTP”. From this log output, we can conclude that the query cache is working.
You can also pass a file name to
startLog. This makes it easier to read the log output back in as a
data.frame and analyze it quantitatively. We'll do an example of that below.
You may want to send other events to the log, interspersed with your HTTP requests, whether for their own sake or to see how work done in R outside of the HTTP layer maps onto your server traffic. The function
logMessage writes to the connection specified by
startLog, and it is available for general use. For error logging, the
halt function wraps
stop and sends a message to the log (it also makes the awkwardly named
call. argument to
stop default to
FALSE for cleaner error messaging).
As the saying (or joke, depending on the version), cache invalidation is one of the two hard problems in computer science. The trouble with caching what the server serves is that the server is the source of truth, and if the state of data on the server changes, our local copy of the data is stale. In some applications and with some APIs, we have no idea when the server state changes, but in many cases, the source of change on the server is actions that we initiate ourselves. In these cases, a local query cache is more feasible, and cache invalidation more tractable.
httpcache provides some functions to direct cache invalidation. We've seen one already,
clearCache, which wipes the entire cache. Other functions give more surgical control.
invalidates cache only for the specified URL.
regular expression matching to invalidate cache.
dropCache is a
convenience wrapper around
dropPattern that invalidates cache for
any resources that start with the given URL.
Depending on the API with which you're communicating, you may not need to use those cache-invalidation functions directly, or you may need them only infrequently.
httpcache was designed with RESTful APIs in mind, particularly those that expose resources that contain collections of entities that can be created, replaced, updated, and deleted with POST, PUT, PATCH, and DELETE, respectively. Consequently, these four HTTP verb functions are built with default cache invalidation actions:
POST invalidates cache only for the request URL (
dropOnly), for the case where POST creates a new entity appearing as a subresource. For example, if
GET http://api.example/projects/ returns a catalog of project entities, and POST to
http://api.example/projects/ creates a resource at
http://api.example/projects/new_id/, we need to bust cache for the project catalog on POST, but our cached responses for resources such as
http://api.example/projects/old_id/ should still be valid. The other three functions,
DELETE, by default drop cache for the request URL and everything “below” it (
dropCache). Continuing with the example, if we modify
http://api.example/projects/new_id/, we should invalidate cache for that resource and for other resources appearing as subresources of it, such as
These verb functions (
DELETE) all take a
drop argument, which defaults as described above. To override them, you can specify a different call other than
dropOnly(url), or you can pass
drop=NULL and call the cache-invalidation functions directly. Depending on your API and your usage of it, however,
httpcache's cache management may just work for you with no additional effort.
For a more complete example of the caching, logging, and invalidation features, we'll use a mock HTTP interface that allows demonstration of the features of
httpcache without requiring a network connection. Refer to the setup code in the test suite for specifics. We'll make a series of requests, both reads and writes, and we'll capture the action with the logging tools.