Does WP REST API cache internally executed (rest_do_request) requests?

Question

We have registered a custom REST GET endpoint using register_rest_route(), consisting in the retrieval of posts of a custom post type (my_custom_post). We're using our own endpoint to do so as we do not want to allow direct requests to the endpoint of the concerned post type.

Code Example:

Plugin File Content:

add_action(
    'rest_api_init',
    function () {
        register_rest_route(
            'namespace',
            '/endpoint',
            [
                [
                    'methods'  => 'GET',
                    'callback' => [
                        SampleController::class,
                        'test'
                    ],
                    'args'     => [
                        'test' => [
                            'type'        => 'string',
                            'description' => 'This is just a test',
                            'required'    => true
                        ]
                    ]
                ]
            ]
        );
    }
);

Request Controller:

class SampleController {
    
    public static function test( WP_REST_Request $request ):WP_REST_Response
    {
    
        $search_request = new WP_REST_Request(
            method: 'GET',
            route:  '/wp/v2/my_custom_post'
        );
        
        $search_request->set_param(
            '_fields',
            'id,meta.my_custom_meta'
        );
        
        $search_response = rest_do_request($search_request);
    
        $search_response_data = rest_get_server()->response_to_data(
            response: $search_response,
            embed:    false
        );
    
        $answer = new WP_REST_Response(
            [
                'success' => true,
                'message' => $search_response_data
            ],
            200
        );

        $answer->header(
          key: 'Cache-Control',
          value: 'no-cache',
          replace: true
        );

        return $answer;
        
    }
    
}

JavaScript:

async function sendRequest() {
    
    const response = await fetch(
        'https://example.org/namespace/endpoint?test=hello',
        {
            method : 'GET',
            headers: {
                'Content-Type':'application/json',

            },
            mode   : 'same-origin',
            cache  : 'no-cache'
        }
    );
    
    const responseData = await response.json();

    if (!response.ok || response.status !== 200) {
        throw Error('An Error ocurred');
    }
    
    return responseData;
    
}

The requests to the endpoint do not report any errors ever, and everything works fine.

The problem is that, let's say you have 6 posts of the type my_custom_post. Via the code above, you fire the request once, and get your data. You then go to the WP Admin, update exclusively the my_custom_meta of 2 of your posts, and then fire the request again. Problem: the changes are not immediately reflected in your returned response; it always takes about 10 minutes and / or multiple requests. And this although we're applying the Cache-Control: no-cache headers to our request as well as to the response.

So we wonder, does wordpress actually cache responses of internally executed REST API requests on the server-side? Or what is happening here?

We've also tried to apply the Cache-Control headers to our internal request, by changing the body of the Controller's test method above to:

...
$search_request->set_param(
    '_fields',
    'id,meta.my_custom_meta'
);

$search_request->set_headers(
    headers:  [ 'Cache-Control' => 'no-cache' ],
    override: false
);

$search_response = rest_do_request($search_request);

$search_response->header(
    key:     'Cache-Control',
    value:   'no-cache',
    replace: true
);
...

But the problem persists.

We've then also heard about the rest_send_nocache_headers hook thanks to this ticket; but we're unsure about how applying that filter to a specific REST API namespace only (because we basically do not want any of our endpoints of a specific namespace to return cached responses).

Answer 1

Does WP REST API cache internally executed requests?

No it does not, not out of the box. CDNs and caching plugins can and do interfere however, especially for unauthenticated REST requests.

As an example to demonstrate this with hard results and test my own conclusion I added a random number generator to my site:

https://tomjn.com/wp-json/tomjn/v1/random

This is the code:

function tomjn_rest_random() {
        return rand(1,100);
}       

add_action( 'rest_api_init', function () {
    register_rest_route( 'tomjn/v1', '/random/', [
        'methods' => 'GET',
        'permission_callback' => '__return_true',
        'callback' => 'tomjn_rest_random',
        'show_in_index' => false,
    ] );
} );

This includes rest_do_request, WordPress has no page/response level caching built in, these are all provided by 3rd party services/software.

Note though that WP does cache some functions if a dedicated object cache is present, but never anything as large as an entire REST API response. This is on the scale of individual posts/terms/meta fetched from the database, or expensive calls such as figuring out post counts for a category, smaller atomic pieces of data that aren't enough to explain your results.

A Note on HTTP request/response cache headers

no-cache does not do what you think it does! It means cache the result, but mandates that a request must be made to validate that it's still current. So unless you've implemented etags etc the browser might not realise the response has changed, especially since this isn't a static file.

From MDN:

The no-cache response directive indicates that the response can be stored in caches, but the response must be validated with the origin server before each reuse, even when the cache is disconnected from the origin server.

If you want caches to always check for content updates while reusing stored content, no-cache is the directive to use. It does this by requiring caches to revalidate each request with the origin server.

Note that no-cache does not mean "don't cache". no-cache allows caches to store a response but requires them to revalidate it before reuse. If the sense of "don't cache" that you want is actually "don't store", then no-store is the directive to use.

Instead consider using no-store:

The no-store response directive indicates that any caches of any kind (private or shared) should not store this response.

Further reading:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
• https://hacks.mozilla.org/2016/03/referrer-and-cache-control-apis-for-fetch/