API-warmer’ы

API астуджаюцца гэтак жа, як і вэб-старонкі. Калі стварэнне адказу JSON каштуе дорага і кэшуецца ў вашым CDN або шлюзе, першы кліент пасля заканчэння тэрміну дзеяння плаціць такі ж штраф, як і наведвальнік вэб-сайта.

API warmers вырашае гэта. Яны кіруюцца асобна ад вэб-сайта warmers, у раздзеле Уліковы запіс → API Warmers, і яны маюць уласныя ліміты плана.

Калі выкарыстоўваць адзін#

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

Стварэнне API warmer#

1. 1

   Праверце API hostname

   Канчатковыя URL-адрасы павінны выкарыстоўваць правераныя hostname, сапраўды гэтак жа, як вэб-сайт warmers. Глядзіце [Hostname праверка] (/documentation/hostname-verification).

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 або абнавіце.

Аўтэнтыфікацыя#

Глабальныя загалоўкі запытаў і кукі прымяняюцца да кожнага варыянту, які стварае 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

Абнавіце http:// URL канчатковых кропак да https://.

Цёплы графік

Вокны ў пік і па-за піку, той жа фармат JSON, што і на сайце warmers. Глядзіце [Пашыранае пацяпленне] (/documentation/advanced-warming).

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

Агульныя праблемы#

Усё вяртаецца 401 або 403.

Загаловак аўтэнтыфікацыі або файл cookie адсутнічае, няправільны або пратэрмінаваны. Звычайна вінаватымі з'яўляюцца доўгажывучыя токены - праверце, ці токен усё яшчэ дзейнічае і не абмяняўся.

warmer не захавае, спасылаючыся на занадта шмат камбінацый.

Ваша матрыца пашыраецца за максімум плана. Паменшыце значэнні памераў, падзяліце канчатковыя кропкі на некалькі warmers або абнавіце.

Метаду, які мне патрэбны, няма ў выпадальным спісе.

Планы абмяжоўваюць метады HTTP, дазволеныя. Больш нізкія ўзроўні звычайна дазваляюць толькі GET і HEAD.

Разагрэў працуе без праблем, але рэальныя кліенты адказваюць павольна.

Верагодна, вы запаўняеце іншы варыянт кэша, чым запытваюць кліенты — звычайна з-за загалоўка Authorization, файла cookie або загалоўка вашага CDN. Параўнайце дакладны запыт, які дасылае рэальны кліент, з тым, што дасылае warmer.

Ці магу я абагрэць канечную кропку, якая патрабуе падпісанага кароткачасовага токена?

Ненадзейна, таму што warmer не можа стварыць новы подпіс за адзін запуск. Альбо адкрыйце кэшаваны неаўтэнтыфікаваны варыянт, альбо выкарыстоўвайце доўгатэрміновы маркер службы, калі гэта бяспечна.