Timeline for Does WP REST API cache internally executed (rest_do_request) requests?
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 21, 2023 at 9:01 | history | edited | Tom J Nowell♦ | CC BY-SA 4.0 |
added 146 characters in body
|
| Apr 21, 2023 at 7:58 | comment | added | Tom J Nowell♦ | Also note that while my example was simple, I’ve used far more complex endpoints and never had to worry about this before in vanilla WP. If you’re on a managed WP host there’s a very high chance your host is caching unauthenticated REST responses, and that my example has the same problem on your server. Again WP does not cache API responses and does not have that ability. The cache problem is elsewhere | |
| Apr 21, 2023 at 7:57 | comment | added | Tom J Nowell♦ | No, no there is not. WordPress does not cache REST API responses. Your nested call does not add an opportunity to bust WP cache because there is none to bust. HTTP cache control headers don’t influence WP behaviour they influence external behaviour. It’s far more likely that you have a CDN or caching layer in front of WordPress such as cloudflare, or that you’ve directed the browser to perform browser caching. The complexity of the REST API endpoint is irrelevant here, unless you yourself added caching WP does not cache API responses. It doesn’t even have the code to do so | |
| Apr 21, 2023 at 0:35 | comment | added | DevelJoe |
And if I may add a thought; in our use-case vs your example, there's an additional REST API request executed via rest_do_request, hence an additional chance for a cache bust / revalidation may being necessary for that. There are some questions in this forum mentioning the issue of unwanted cached responses to the WP Post API. It theoretically makes sense that API requests involving DB queries (as queries for posts) involve a different way of caching vs your example; which is a simple script. Maybe that explains why the Cache-Control stuff was required in our case, but not in your example.
|
|
| Apr 21, 2023 at 0:24 | comment | added | DevelJoe |
Notes: MDN mentions this on no-store vs no-cache, which is why we favored no-cache, following their recommendation. We've been using no-store previously; but MDN also mentions that the major browsers do not support requests with no-store. Try a fetch request with no-store in Firefox, and you'll see that the HTTP Request header sent will be no-cache automatically, instead.
|
|
| Apr 21, 2023 at 0:12 | vote | accept | DevelJoe | ||
| Apr 21, 2023 at 0:11 | comment | added | DevelJoe |
EDIT: We've just discovered now that there was a deployment error, and that the lines $answer->header( key: 'Cache-Control', value: 'no-cache', replace: true ); have not been deployed to our code (to enforce cache-revalidation not only on the client-side, but also on the server-side). With this, it's all fully working now, so it seems to be manadatory to enforce cache revalidation not only on the client, but also on the server-side, makes total sense actually.
|
|
| Apr 20, 2023 at 14:42 | history | answered | Tom J Nowell♦ | CC BY-SA 4.0 |