Wordpress LScache Plugin: Cache public GET requests to WP API endpoints
Last Updated on: Wed, 15 Apr 2026 00:00:02 Working with WP API to fetch posts, I quickly realised that a server-side cache solution for this type of requests would be a great improvement. Actually, the only solution I know is the WP REST API Cache plugin, but it uses transients to store the cached object, which means the use of PHP and database by default. Caching public GET requests to WP API endpoints is a feature currently discussed in other cache plugins, like WP Super Cache, and I think it would a really nice feature to add to LiteSpeed cache. This way, no matter if you fetch a post as a HTML document or as a JSON document, both documents would be cached and both would be deleted/refreshed in sync. What do you think about this feature? Is it possible, practical and worth to implement? This topic was modified 5 years, 3 months ago by cybmeta. Hi @cybmeta, Did you mean cache posts/post data when fetch data from wp via API like curl http://demo.wp-api.org/wp-json/wp/v2/posts? Its a really nice idea. We will add WP REST API cacheable functionality in next release. Supposed to be in next week. Thanks, for you suggestion. Hai Yes, I meant exactly that. AwsomeThank you very muchExcellent idea. Hi @cybmeta, We have finished Retrieve a Post cache part: Definition #Definition GET /wp/v2/posts/ Example Request #Example Request $ curl http://demo.wp-api.org/wp-json/wp/v2/posts/ > https://developer.wordpress.org/rest-api/reference/posts/#retrieve-a-post Can you suggest which other GET requests should be cached? What about posts collections?: #Definition GET /wp/v2/posts/ #Examples $ curl http://demo.wp-api.org/wp-json/wp/v2/posts $ curl http://demo.wp-api.org/wp-json/wp/v2/posts?per_page=20 $ curl http://demo.wp-api.org/wp-json/wp/v2/posts?categories=5,45 > https://developer.wordpress.org/rest-api/reference/posts/#list-posts Pages #Definition GET /wp/v2/pages/ #Example Request $ curl http://demo.wp-api.org/wp-json/wp/v2/pages/ > https://developer.wordpress.org/rest-api/reference/pages/#retrieve-a-page And pages collections? #Definition GET /wp/v2/pages #Examples $ curl http://demo.wp-api.org/wp-json/wp/v2/pages $ curl http://demo.wp-api.org/wp-json/wp/v2/pages?per_page=5 $ curl http://demo.wp-api.org/wp-json/wp/v2/pages?per_page=5&author=9 > https://developer.wordpress.org/rest-api/reference/pages/#list-pages Maybe for future releases you can take into consideration to support all the core object types: users, taxonomies, comments What about posts collections: #Definition GET /wp/v2/posts #Example Request $ curl http://demo.wp-api.org/wp-json/wp/v2/posts $ curl http://demo.wp-api.org/wp-json/wp/v2/posts?categories=2,5&author=9 > https://developer.wordpress.org/rest-api/reference/posts/#list-posts Pages #Definition GET /wp/v2/pages/ #Example Request $ curl http://demo.wp-api.org/wp-json/wp/v2/pages/ > https://developer.wordpress.org/rest-api/reference/pages/#retrieve-a-page And pages collections? #Definition GET /wp/v2/pages #Example Request $ curl http://demo.wp-api.org/wp-json/wp/v2/pages $ curl http://demo.wp-api.org/wp-json/wp/v2/pages?per_page=4&parent=89 > https://developer.wordpress.org/rest-api/reference/pages/#list-pages For future releases you can take into consideration to add support for the other object types in core: users, taxonomies, comments and media. Added. Thanks for suggestion. All rest requests will be cached now. Lets see in next release. Or maybe, you can cache all GET request to /wp-json/ , that is, cache ALL GET resqust to the base url of the REST API. Tha would include all registered namespaces and routes. When a route doesnt exist, the REST API respond with a 404 status. When the user has not enough priviliges, the REST API respond with a 401 status. So, I think that handle ALL GET requests to the REST API could be interesting, at least to investigate.
LiteCache Rush: Speed comes from using less, not from doing it faster
Reference