Zarejestrowaliśmy niestandardowy punkt końcowy REST GET za pomocą register_rest_route()polegający na wyszukiwaniu postów o niestandardowym typie postu (my_custom_post). Używamy do tego własnego punktu końcowego, ponieważ nie chcemy zezwalać na bezpośrednie żądania do punktu końcowego danego typu postu.

Przykład kodu:

Zawartość pliku wtyczki:

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
                        ]
                    ]
                ]
            ]
        );
    }
);

Kontroler żądań:

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(
        '
        {
            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;
    
}

Żądania do punktu końcowego nigdy nie zgłaszają żadnych błędów i wszystko działa dobrze.

Problem polega na tym, że powiedzmy, że masz 6 postów tego typu my_custom_post. Za pomocą powyższego kodu uruchamiasz żądanie raz i otrzymujesz dane. Następnie przejdź do administratora WP, zaktualizuj wyłącznie plik my_custom_meta z 2 Twoich postów, a następnie ponownie wyślij żądanie. Problem: zmiany nie są natychmiast odzwierciedlane w zwróconej odpowiedzi; zawsze zajmuje to około 10 minut i/lub wiele próśb. I to chociaż stosujemy Cache-Control: no-cache nagłówki do naszej prośby, jak również do odpowiedzi.

Zastanawiamy się więc, czy wordpress faktycznie buforuje odpowiedzi wewnętrznie wykonywanych żądań API REST po stronie serwera? Albo co się tutaj dzieje?

Próbowaliśmy również zastosować tzw Cache-Control nagłówków na nasze wewnętrzne żądanie, zmieniając treść Administratora test powyższą metodę, aby:

...
$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
);
...

Ale problem nie ustępuje.

Wtedy też słyszeliśmy o rest_send_nocache_headers haczyk dzięki temu biletowi; ale nie jesteśmy pewni, jak zastosować ten filtr tylko do określonej przestrzeni nazw interfejsu API REST (ponieważ zasadniczo nie chcemy, aby żaden z naszych punktów końcowych określonej przestrzeni nazw zwracał odpowiedzi z pamięci podręcznej).