Pokročilejší transformace volání v Azure API Management
O Azure API Management už jsem psal a dnes si ukážeme příklad o něco složitějších transformací. Máte API, které není RESTful a připomíná spíše JSONové RPC přes http? Podívejme se, jak se dá transformovat na moderní API, které bude každému vývojáři vyhovovat.
Představme si následující situaci a reálné nejmenované API, s kterým jsem si hrál. To využívalo na všechno metodu POST, zatímco RESTful přístup využívá vícero http sloves (GET pro čtení, POST pro vytvoření, PUT pro vytvoření nebo modifikaci, DELETE pro výmaz a PATCH pro jednoduchou modifikaci). Samotné sloveso bylo v URL, například /get/device, /create/device nebo /delete/device. Dále přihlašovací údaje, token nebo verze API bylo přímo v JSON s dotazem, který byl součást body, zatímco u RESTful tohle typicky chcete v headeru. Samotný dotaz byl formulován jako JSON v body – to je u RESTful běžné pro POST nebo PUT, ale čtení a filtrování typicky řešíte jako query v GETu. API vždy vracelo 200 z HTTP hlediska a uvnitř response body byl JSON obsahující položku error_code. V RESTful přístupu chcete využít http kódů přímo v odpovědi jako je 200 pro OK, 201 pro vytořeno, 202 pro přijato, 400 pro špatně formulovaný dotaz, 401 při selhání autentizace nebo 403 při selhání autorizace (uživatel je v pořádku, ale k této informaci nemá přístup).
Jak by se dalo toto API transformovat na RESTful s využitím Azure API Management?
Liquid syntaxe v set-body
Nejprve samozřejmě nadefinujeme novou podobu API, ale při volání na backend musíme provést transformace. Prvním způsobem při vytváření potřebného JSON je Liquid syntaxe (podobná například Jinja2 template v Pythonu).
Mějme na vstupu GET namířený na /devices, definovaný parametr count a offset a definovaný header s tokenem. Jak tohle dostat do POST volání a zakomponovat do JSON v body tak, jak to starší API potřebuje?