I'm am currently trialling the new (as of 2017) core API built into Wordpress. My setup is reasonably simple:

 +---------+    +------+    +---------+
 |Wordpress|<-->|Guzzle|<-->|   App   |
 |(API)    |    +------+    |(PHPSlim)|
 +---------+                +---------+

Guzzle will be operating through a local loopback (/etc/hosts set up to see the api as a local resource).

The major players in the WP space for cacheing (WP Super Cache, W3, etc) don't appear to do anything around the API. My understanding is that they essentially create snapshots of a rendered page and skip over any php (including db calls) for future requests.


The question is, is it possible to apply a level of cache to the API calls in WP? The site is reasonably static, so ideally I don't want to ping the DB for every request.

I have examined the headers returned by WP and no cacheing indicators are present. I have also considered using wp_cache functions or wp_transient functions, but both seem to be a misuse of their functionality.

Headers: enter image description here

  • 1
    I don't know about caching core API requests, but Memcached (memcached.org) seems to be a good solution for caching API requests generally. – Lucas Bustamante Jul 30 '18 at 22:19
  • I agree with using something like memcached or redis (redis.io). These can cache pretty much everything WordPress does. The biggest overhead in any request is the database, so you really want to be caching that and not the REST API itself (unless you have some oddly-specific use-case). If the reason you want caching is because there's too much strain on your server, then anything that caches the database should sufficiently help alleviate that strain. – phatskat Apr 2 '19 at 1:04

There is a cache plugin for WP Rest API with the name... WP Rest API Cache:

I've used it for small projects and helped me a lot.

  • 1
    Interesting. Looking at the source (github.com/airesvsg/wp-rest-api-cache/blob/master/…) it seems that it uses transient functions within Wordpress. Reading the docs (codex.wordpress.org/Transients_API), that does seem to line up to the purpose of transient functions. I don't know if I will use that specific plugin, but I will use that approach. Thanks! – Chris Mar 29 '17 at 0:57
  • Transients can be used for this purpose and if you are using an persistent cache backend, it will be pretty much efficient. I am using it with commom HTML markup generated by some ajax functions and Local Storage (or Session Storage in some cases) and will test it with WP Rest Api soon. Also, if you are using javascript, you should test Service Workers + Cache Storage as well. – Celso Bessa Mar 29 '17 at 2:16
  • Nice one. Out of interest, are you blogging your test cases or anything like that? – Chris Mar 29 '17 at 4:02
  • GRRRRR this is an API, and you should obviously not cache API call results. The plugin also do not indicate compliance with the wordpress 4.7 version. Anyway good answers should be more than a link, either they should have a code, or if you point to external resource should have a much better description of how it works or should be configured instead of letting people go and dig for the information. – Mark Kaplun Mar 29 '17 at 5:38

It is an API.... would you like to get stale cached results when doing $i++? I guess not.

Caching should be done on the user side of the API as only it can know what is the level of staleness that can be tolerated.

It is not like you should avoid any type of caching on the wordpress side, but keep in mind that to do cache invalidation is a bitch. The safest way to go is with object caching which you should have in any case on any serious wordpress deployment.

  • While I agree in general, typically (outside of WP) its the backend or resource owner that flags a resource expiry, and then the cache systems at various points, be it your browser, app, exchange, etc need to determine what to do with said expiry – Chris Mar 29 '17 at 6:01
  • @chris, I am seriously interested to know which "major" API provider serves results that may be cached by proxies. If you need some data which can be cached you should design your own end point, something like RSS, which is explicitly known to be stale. Don't forget that with time you might want to use the REST API for some other usage which can not tolerate staleness, what do you do than? The one size fits all plugin solution propossed in the other answer is truly bad idea. – Mark Kaplun Mar 29 '17 at 8:18
  • I feel like we are talking about different things, or we're at least misunderstanding each other. My rep here is far lower than over on SO - so feel free to edit the question if it doesn't fit the parameters of this site. Coming from Laravel, where I can explicitly control all request headers, I would typically cache expensive queries and send back request headers to let the client know how to proceed. Eitherway I have unmarked the other as correct to see if a better answers come out of this conversation. – Chris Mar 29 '17 at 11:13
  • 1
    @Chris, I am not even a newbe in laravel so maybe what I think is wrong, but don't you craft your own end points there, and have a specific control on each one? When you do that you can decide that API X might return values that are 30 min stale, and everybody is happy because that is the definition of the API, and people that are not happy with it should not use it. In wordpress the REST API is provided by core (and if you are not talking about it, than an edit to the question is needed), and it is not assumed to return stale valuesyou are the only user of it – Mark Kaplun Mar 29 '17 at 13:55
  • 1
    ... therefore adding caching headers to it will be a violation of the definition of the API. It is not a very bad thing if you are the only user of the API, but you might want to add some plugin that gets recent posts via the API, and now, suddenly instead of getting a fresh list, it is getting stale one which might be very bad if you are using it to publish some of real time game results. Therefor you need to be sure that no one ever will use the rest API with different caching requirements than your current feature needs. – Mark Kaplun Mar 29 '17 at 14:02

This one below is actually better I believe:


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.