Акценти
Кликнете върху произволен request в Activity сега и ще видите пълния payload. Още един клик го отваря обратно в Playground, предварително попълнен и готов за повторно стартиране. Също така уловихме клас от "proxy", който връща обратно вашия собствен request като фалшив response, и го спряхме да замърсява данните ви.
Какво ново
Activity → Playground: повторно изпълнение на всеки request
Всеки API call се връща с X-Foura-Request-Id header. Същото id се показва до request в Activity. Кликнете върху произволен ред и ще получите пълната картина: кога се е изпълнил, кой ключ го е направил, request body, response, status codes и времето, което е отнело. Кликнете върху "Open in Playground" и request се зарежда във формата, предварително попълнен.
Преди повторното изпълнение означаваше да изградите отново request по памет. Сега Activity пази историята, а Playground е бутонът за повторно стартиране.
Няколко технически подробности, които трябва да знаете. Пазим последните 200 payloads за всеки API key в продължение на 24 часа. След това по-старите записи отпадат с постъпването на нови. Когато даден payload е остарял, диалоговият прозорец ви уведомява, вместо да показва объркващо null или "(empty body)", както преди.
Също така можете да съпоставите и request id. Запишете в лога X-Foura-Request-Id response header до вашето собствено request id от страна на клиента и намирането на съответния ред в Activity по-късно ще отнеме само едно поставяне.
Заснемането се извършва извън критичния път (hot path). Вашият API request никога не го чака. И ако хранилището за заснемане е недостъпно, повикването пак се извършва, а диалоговият прозорец просто показва "no body captured" по-късно.
Валидиране спрямо response body
Секцията Validate в Playground получи правила за съдържанието на body. Можете да зададете "успех само ако response съдържа X" или "неуспех, ако съдържа Y", с множество алтернативи, разделени с |. Работи за Single и Proxy. Полезно е, когато status codes лъжат за това какво действително се е случило.
Payloads без body се самообясняват
Неуспешните requests нямат response body, което да се покаже. Старият диалогов прозорец изобразяваше това като null или "(empty body)", което лесно можеше да се разтълкува погрешно като реален празен response. Сега диалоговият прозорец разграничава три случая: request се е провалил (с действителното съобщение за грешка), не е заловен payload или сървърът наистина е върнал нула байта.
Дребно нещо, но премахва повтарящия се момент на чудене "чакай, това response ли беше или бъг в интерфейса?".
Бутон за нулиране в Playground
Връща формата на активния endpoint към настройките по подразбиране с един клик. Настройките по подразбиране запазват unblocker и tryJsonData включени, тъй като това е пътят в 90% от случаите.
Под капака
Засичане на honeypot proxy
Някои "proxies" в реалния свят всъщност не препращат. Те връщат обратно вашия собствен request като обикновен текстов dump на променливите на сървъра (HTTP метода, headers, целевия host), за да може операторът да събере всичко, което е било в него. Виждали сме едно и също proxy да препраща един request, да връща обратно следващия и да дава 502 на по-следващия, и всичко това в рамките на една сесия.
Валидаторът на body сега засича сигнатурата на този dump, преди response да напусне нашия edge. Single връща честен неуспех. Proxy Finder опитва отново с различно proxy. Browser наследява същата защита от споделения HTTP слой. Така ще виждате по-малко излишни редове в Activity, а вашите scrapers няма да приемат нещо, което изглежда като данни, но всъщност е сонда.
Все още няма промяна в репутацията. proxy остава в пула за момента. Ние просто отказваме да ви върнем неговата лъжа.
Така че: ако даден request попадне в Activity, маркиран като твърд неуспех, където преди е изглеждал като крехък "успех", това е защитата, която го улавя. По-добре чист неуспех, отколкото отровен запис.