кеш при обновлении записей? (HttpPut/HttpDelete/HttpPost)
aspnet core 2.2 web api
Неа, ResponseCache задает http-заголовки для ответа и клиент сам решает, нужно ли ему перекачивать данные или нет
Посмотрите в сторону засовывания хэшсуммы в ETag header
Кэш не статического контента дело тонкое. Если клиенту просто сказать что нужно кэшировать какой то ресурс, то он не пойдет за данными на сервер, пока не закончится срок дейсвтия кэша. HTTP запроса вообще не будет. Тут можно накасячить, и закэшировать данные которые могут изменится, но мало кто об этом узнает в срок. Если вам нужно чтобы килент всегда работал с актуальными данными: 1) Можно реализовать разные URI, queryString например с версией ресурса. В таком случае стандартный механизм кэширования подойдет, если версия не изменилась, то HTTP запрос не пройдет дальше локального кэша браузера. Если версия изменилась то пройдет новый запрос, и сразу же закэшируется под новым URI, до тех пор пока не истечет кэш или обновится версия ресурса. Например фото сущности, в JSON летит версия, она проставляется в параметрах запроса. Если такая версия уже была в кэше браузера клиента, то запроса не будет, если нет, то запросится и попаде в кэш. 2) Etag. Клиент отправит HTTP запрос на сервер, сервер сравнит Etag от клиента и Etag запрашиваемого ресурса, если они совпали то ресур не изменился и ответ будет с кодом 304, если изменлся то вернется ресурс с новым Etag. В этом случае HTTP запрос будет всегда, но вот тело ответа может быть пустым (оптимизация хотя бы на этом). Выгода ощутима только если ресрс большого объема. Всякие либы которые прописаны в HTML могут кэшируются на долго, просто при изменении их версии, нужно менять имена этих либ. Это аналогично трюку под #1 описанному выше.
Обсуждают сегодня