HTTP-кэширование для аутентифицированных REST API

#rest #api #http #caching

#rest #API #http #кэширование

Вопрос:

В настоящее время я создаю REST API. Многие ресурсы, которые я создаю, всегда будут идентичны, независимо от того, кто обращается к ресурсу. Те немногие, которые не являются, будут иметь Vary: Authorization заголовок.

Есть два исключения:

  1. Вы получите ответ 401, если вы не прошли проверку подлинности.
  2. Вы можете получить ответ 403 для некоторых ресурсов, к которым у вас нет доступа.

Мой вопрос в том, будет ли в этом случае по-прежнему возможно правильно настроить кэширование. В частности, я хотел бы использовать обратный прокси, такой как nginx, varnish или haproxy, для разгрузки основного сервиса.

Существуют ли элегантные решения этой проблемы?

Комментарии:

1. Совпадают ли URI изменяющихся ресурсов с теми, которые этого не делают? например, есть ли у вас /user /joe, который либо возвращает общедоступную информацию, либо информацию, видимую только некоторым пользователям, либо информацию, видимую только Joe?

2. @Nicholas возможно, я выразился не совсем ясно, но для большинства ресурсов это не тот случай, а для тех, которые есть, они будут иметь Vary: Authorization . Меня интересуют только ресурсы, которые не похожи на эти. У них всегда один и тот же ответ для 200 OK, или они равны 401/403.

Ответ №1:

Vary: Authorization не требуется; ответы на запросы с авторизацией автоматически становятся частными и не будут кэшироваться общими кэшами.

Вы можете отправить Cache-Control: public , чтобы переопределить это; ответы с этим могут быть кэшированы с использованием обычных правил.

Однако, если вы хотите, чтобы эти ответы оставались аутентифицированными, вам необходимо ввести аутентификацию. Вы можете сделать это, также отправив Cache-Control: no-cache , что заставит кэш свериться с источником перед отправкой сохраненного ответа.

Если вы просто хотите, чтобы кэширование выполнял ваш обратный прокси (например, Varnish, nginx), вполне вероятно, что у него есть способ настройки для наложения аутентификации на «edge», обслуживающий ответы из кэша, когда запрос имеет надлежащую аутентификацию. Проверьте его документацию для получения подробной информации.

Комментарии:

1. Спасибо! Всегда здорово получить ответ прямо из источника 🙂

2. Как Cache-Control: no-cache помогает с установлением аутентификации? Это потому, что он попытается повторно проверить кэшированный элемент на сервере, что означает, что он должен отправить запрос, и этот запрос должен быть аутентифицирован, чтобы даже получить 304 с сервера?