API-warmer’ы

API остывают точно так же, как и веб-страницы. Если создание ответа JSON требует больших затрат и он кешируется в вашей CDN или шлюзе, первый клиент после истечения срока действия платит тот же штраф, что и посетитель веб-сайта.

API warmers решит эту проблему. Они управляются отдельно от веб-сайта warmers в разделе Аккаунт → API Warmers и имеют собственные ограничения плана.

Когда использовать один#

API warmer бесполезен для конечных точек, которые никогда не кешируются или которые уникальны для каждого пользователя и, следовательно, не имеют общей кешированной копии для заполнения.

Создание API warmer#

1. 1

   Проверьте API hostname

   URL-адреса конечных точек должны использовать проверенный hostname, точно так же, как веб-сайт warmers. См. Hostname проверка.

2. 2

   Назовите warmer и оставьте его неактивным.

   Сначала настройте, активируйте, когда будете удовлетворены.

3. 3

   Добавьте одну или несколько конечных точек

   Каждая конечная точка имеет URL-адрес и метод HTTP, а также, при необходимости, метку, текст и тип контента.

4. 4

   Добавьте аутентификацию, если она нужна конечной точке

   Глобальные заголовки и файлы cookie применяются к каждому запросу, который делает warmer.

5. 5

   При необходимости расширить матрицу конфигурации.

   Охватывайте множество вариантов — локали, арендаторов, идентификаторы — без создания десятков почти идентичных warmers.

6. 6

   Установите скорость и интервалы, затем активируйте

   Та же идея, что и у веб-сайта warmers: нагреваться достаточно часто, чтобы превзойти TTL вашего кеша, и достаточно медленно, чтобы не повредить.

Конечные точки#

Каждая конечная точка в warmer настраивается независимо:

Этикетка

Необязательное удобочитаемое имя, поэтому длинный список конечных точек остается читабельным.

URL-адрес

Полный адрес конечной точки на проверенном hostname. Может содержать заполнители пути, такие как {id} или :id, в сочетании с измерением PATH.

Метод

GET, POST и другие в зависимости от вашего плана. Планы обычно допускают GET и HEAD по умолчанию, с большим количеством методов на более высоких уровнях.

Протокол

REST или GRAPHQL. Выбор GraphQL открывает поля операции и запроса.

Шаблон тела запроса

Тело для отправки для методов, которые его несут. Требуется право на тело запроса API.

Тип контента

Тип содержимого тела запроса, обычно application/json.

Идемпотент

Помечает конечную точку как безопасную для двойного вызова, позволяя выполнять двойную выборку холодного/теплого трафика, которая измеряет улучшение. Включайте его только при двойном вызове, это не имеет побочных эффектов.

Включено

Включена ли эта конкретная конечная точка в прогоны. Удобно для временного отключения одной конечной точки без ее удаления.

Матрицы конфигурации#

У большинства API есть варианты: одна и та же конечная точка, вызываемая для каждого языкового стандарта, каждого клиента, каждой валюты или каждого идентификатора. Создать warmer для каждого невозможно.

Матрица конфигурации решает эту проблему. Вы определяете измерения с несколькими значениями, а Cache Rocket разбивает полное декартово произведение на отдельные теплые запросы.

Проработанный пример

Endpoint:  GET https://api.example.com/v1/products/{category}

Dimensions:
  PATH   category = shoes, bags, hats
  QUERY  locale   = en, nl

Expands to 6 warm requests:
  /v1/products/shoes?locale=en
  /v1/products/shoes?locale=nl
  /v1/products/bags?locale=en
  /v1/products/bags?locale=nl
  /v1/products/hats?locale=en
  /v1/products/hats?locale=nl

Если вы превысите максимум плана, warmer не сохранится. Уменьшите значения, разделите их на несколько warmers или обновите.

Аутентификация#

Глобальные заголовки запросов и файлы cookie применяются к каждому варианту, генерируемому warmer. Сюда помещается заголовок Authorization или файл cookie сеанса.

Authorization: Bearer YOUR_LONG_LIVED_TOKEN
X-Api-Key: YOUR_API_KEY

Срок действия токенов истекает. Если API warmer внезапно начинает возвращать 401, первое, что нужно проверить, — это жестко запрограммированный токен.

GraphQL#

GraphQL требует своего собственного лечения, поскольку производительность зависит от конкретной операции, а не от пути к конечной точке. Нажатие /graphql один раз ничего вам не скажет; разогрев трех самых тяжелых запросов расскажет вам все.

Установите для протокола конечной точки значение GraphQL, затем введите:

• GraphQL операция — будь то query или mutation. Потепление мутаций почти никогда не целесообразно.
• GraphQL запрос — документ операции для отправки.
• Переменные — укажите их через шаблон тела запроса или как значения измерений матрицы для объединения нескольких наборов переменных.

Импорт OpenAPI#

В поддерживаемых планах вы можете импортировать конечные точки прямо из спецификации OpenAPI 3, а не вводить их вручную. Вставьте URL-адрес спецификации JSON или YAML и нажмите Импортировать; обнаруженные конечные точки добавляются к warmer и готовы к обрезке и настройке.

Ограничения и планирование#

Максимальное количество тепла в минуту

Потолок ставки для этого API warmer, что эквивалентно максимальному количеству URL-адресов в минуту на веб-сайте warmer.

Запросить тайм-аут

Как долго ждать ответа, прежде чем сдаваться.

Интервал автоматического запуска

Как часто начинается новый теплый проход, в секундах.

Интервал постановки в очередь

Темп повторной постановки работы в очередь внутри цикла.

Переписать на HTTPS

Обновите URL-адреса конечных точек http:// до https://.

Теплый график

Пиковые и внепиковые периоды, тот же формат JSON, что и на веб-сайте warmers. См. Расширенное потепление.

Ваш план также ограничивает количество API warmers, конечных точек на warmer и комбинаций на warmer.

Распространенные проблемы#

Все возвращает 401 или 403.

Заголовок аутентификации или файл cookie отсутствуют, неверны или срок их действия истек. Обычно виноваты долгоживущие токены — убедитесь, что токен все еще действителен и не менялся.

warmer не спасет, так как указано слишком много комбинаций.

Ваша матрица выходит за пределы планового максимума. Уменьшите значения размеров, разделите конечные точки на несколько warmers или обновите их.

Нужный мне метод отсутствует в раскрывающемся списке.

Планы ограничивают разрешенные методы HTTP. Нижние уровни обычно допускают только GET и HEAD.

Потепление проходит без проблем, но реальные клиенты по-прежнему медленно реагируют.

Вероятно, вы заполняете другой вариант кеша, чем запрос клиентов — обычно из-за заголовка Authorization, файла cookie или заголовка, от которого зависит ваша CDN. Сравните точный запрос, который отправляет реальный клиент, с тем, что отправляет warmer.

Могу ли я обновить конечную точку, для которой требуется подписанный недолговечный токен?

Ненадежно, потому что warmer не может генерировать новую подпись за один прогон. Либо используйте кешируемый неаутентифицированный вариант, либо используйте долгоживущий сервисный токен там, где это безопасно.