Zarejestrowaliśmy niestandardowy punkt końcowy odpoczynku za pomocą register_rest_route() i wysyłają wiele GET prośby do zarejestrowanych GET punkt końcowy. Polega na prośbie o GET niektóre posty niestandardowego typu postów. Problem polega na tym, że mimo, że używamy cache-control: no-store w zgodnie fetch() zadzwoń w javascript; Wydaje się, że odpowiedź została pobrana z pamięci podręcznej; ponieważ wielokrotnie zwracana jest odpowiedź, która nie jest już aktualna.

Czy WP w jakiś sposób implementuje domyślną pamięć podręczną dla swojego interfejsu API REST? Jeśli tak, w jaki sposób ominiemy tę pamięć podręczną i zapewnimy, że każde żądanie skierowane do określonych punktów końcowych API zwróci świeżą, nową odpowiedź i zignoruje pamięć podręczną?

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'
        );
        
// Only get the tags where the associated `my_custom_tag` taxonomy term's value equals the value delivered via the `test` arg. 
        $search_request->set_param(
            'my_custom_tag',
            $request['test']
        );
        
        $search_response = rest_do_request($search_request);
    
        // Retrieve response
        $search_response_data = rest_get_server()->response_to_data(
            response: $search_response,
            embed:    false
        );
    
        return new WP_REST_Response(
            [
                'success' => true,
                'message' => $search_response_data
            ],
            200
        );
        
    }
    
}

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

Problem, przed którym stoimy, to: Załóżmy, że masz 6 postów tego typu my_custom_post. Każdy z tych 6 postów może być powiązany z dokładnie jednym terminem my_custom_tag taksonomia. Wszystkie z nich są obecnie powiązane z terminem, którego wartość to hello.

Jeśli teraz uruchomisz przykładowe żądanie napisane powyżej w javascript, otrzymasz w ten sposób 6 postów w odpowiedzi.

Teraz przejdź do administratora WP i zmodyfikuj wartość terminu my_custom_tag taksonomii 2 z 6 postów na wartość inną niż hello. Następnie wracasz do frontendu i ponownie uruchamiasz żądanie za pomocą javascript.

Problem polega na tym, że nadal otrzymujesz 6 postów i potrzeba wielu próśb/odświeżeń strony/trochę czasu, aby prośba poprawnie zwróciła 4 posty. Co sprawiło, że pomyśleliśmy, że jest to spowodowane jakimś buforowaniem.

Uwaga: Brak zainstalowanych wtyczek, najnowsza wersja WP. Widzieliśmy wtedy ten post wspominający, że API REST WP wysyła do Cache-Control domyślnie z powrotem nagłówek odpowiedzi; co według naszego zrozumienia może prowadzić do niechcianego buforowania odpowiedzi, zwłaszcza jeśli wielokrotnie uruchamiasz je w tym samym punkcie końcowym. Dlatego pomyśleliśmy o dodaniu tzw Cache-Control => no-cache nagłówek odpowiedzi w naszym Kontrolerze test() metoda, jak wspomniano w jednej z odpowiedzi tutaj; ale to również nie rozwiązało problemu.

Czy może to wynikać z faktu, że wewnętrznie wykonujemy żądanie WP REST, a wynik tego żądania jest wewnętrznie buforowany? To znaczy, że powinniśmy może ustawić Cache-Control: no-cache nagłówek na utworzonym $search_request używamy do wewnętrznego żądania? A może jest inne wytłumaczenie, dlaczego tak się dzieje?