{"id":38022,"date":"2019-10-31T22:21:14","date_gmt":"2019-10-31T19:21:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/tak-vse-taki-raml-ili-oas-swagger\/"},"modified":"2019-10-31T22:21:14","modified_gmt":"2019-10-31T19:21:14","slug":"tak-vse-taki-raml-ili-oas-swagger","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/tak-vse-taki-raml-ili-oas-swagger","title":{"rendered":"Deci, RAML sau OAS (Swagger)?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00cen lumea dinamic\u0103 a microserviciilor, orice component\u0103 poate fi rescris\u0103 \u00eentr-o alt\u0103 limb\u0103, folosind cadre \u0219i arhitecturi diferite. Contractele ar trebui s\u0103 r\u0103m\u00e2n\u0103 constant, astfel \u00eenc\u00e2t microserviciile s\u0103 poat\u0103 interac\u021biona extern pe o baz\u0103 constant\u0103, indiferent de metamorfozele interne. Ast\u0103zi, vom vorbi despre dilema noastr\u0103 \u00een privin\u021ba alegerii formatului de descriere a contractelor \u0219i vom \u00eemp\u0103rt\u0103\u0219i artefactele descoperite. <\/p>\n

\"Deci,
\n<\/a><\/noindex>
\nPostarea a fost preg\u0103tit\u0103 Anna Melekhova<\/a><\/noindex> \u0219i Vladimir Lapa\u021bin<\/a><\/noindex> <\/p>\n

Microservicii.<\/b> \u00cen dezvoltarea Acronis Cyber Cloud, am realizat c\u0103 nu ne putem feri de ele. Proiectarea unui microserviciu este imposibil\u0103 f\u0103r\u0103 formalizarea contractului, care reprezint\u0103 interfa\u021ba microserviciului.<\/p>\n

Dar c\u00e2nd produsul con\u021bine mai mult dec\u00e2t o singur\u0103 component\u0103 \u0219i dezvoltarea contractului devine o activitate regulat\u0103, \u00eencepi s\u0103 te g\u00e2nde\u0219ti inevitabil la optimizarea procesului. Devine evident c\u0103 interfa\u021ba (contractul) \u0219i implementarea (microserviciul) trebuie s\u0103 corespund\u0103, c\u0103 diferite componente trebuie s\u0103 fac\u0103 acelea\u0219i lucruri \u00een mod uniform \u0219i c\u0103, f\u0103r\u0103 o decizie centralizat\u0103, fiecare echip\u0103 va fi nevoit\u0103 s\u0103 \u00ee\u0219i piard\u0103 timpul repetat \u00een ob\u021binerea acestor decizii. <\/p>\n

\"Deci,
\nSchema microserviciilor Amazon din tweet<\/a><\/noindex> al lui Werner Vogels, CTO Amazon<\/i>
\nCare este dilema? De facto, exist\u0103 dou\u0103 moduri de interac\u021biune \u00eentre microservicii \u2013 HTTP Rest \u0219i gRPC de la Google. Neav\u00e2nd dorin\u021ba de a fi implica\u021bi \u00een tehnologiile Google, am ales HTTP Rest. Anot\u0103rile pentru contractele HTTP REST sunt, de obicei, descrise \u00eentr-unul dintre cele dou\u0103 formate: RAML \u0219i OAS, anterior cunoscut ca Swagger. Prin urmare, fiecare echip\u0103 de dezvoltatori se confrunt\u0103 cu necesitatea de a alege unul dintre standarde. Dar, dup\u0103 cum s-a dovedit, aceast\u0103 alegere poate fi foarte complicat\u0103.<\/p>\n

De ce sunt necesare anot\u0103rile?<\/h3>\n

\nO not\u0103 explicativ\u0103 este necesar\u0103 pentru ca utilizatorul extern s\u0103 poat\u0103 \u00een\u021belege cu u\u0219urin\u021b\u0103 ce se poate face cu serviciul dvs. prin intermediul interfe\u021bei HTTP. Astfel, la un nivel de baz\u0103, nota trebuie s\u0103 con\u021bin\u0103 cel pu\u021bin o list\u0103 a resurselor disponibile, metodele HTTP, trupurile cererilor, enumerarea parametrilor, specificarea antetelor necesare \u0219i acceptate, precum \u0219i codurile de r\u0103spuns \u0219i formatele r\u0103spunsurilor. Un element extrem de important al notei contractului este \u0219i descrierea verbal\u0103 a acestora (\u201ece se va \u00eent\u00e2mpla dac\u0103 ad\u0103ug\u0103m acest parametru de interogare \u00een cerere?\u201d, \u201e\u00een ce caz va reveni codul 400?\u201d)<\/p>\n

Cu toate acestea, atunci c\u00e2nd vine vorba de dezvoltarea unui num\u0103r mare de microservicii, se dore\u0219te extragerea de beneficii suplimentare din notele scrise. De exemplu, pe baza RAML\/Swagger se pot genera at\u00e2t coduri client, c\u00e2t \u0219i server pentru un num\u0103r uria\u0219 de limbaje de programare. De asemenea, se poate ob\u021bine automat documenta\u021bia pentru microserviciu \u0219i o poate \u00eenc\u0103rca pe portalul dvs. de dezvoltatori :).<\/p>\n

\"Deci,
\nExemplu de descriere structurat\u0103 a contractului<\/i><\/p>\n

Practica test\u0103rii microserviciilor pe baza descrierilor contractelor este mai rar \u00eent\u00e2lnit\u0103. Dac\u0103 a\u021bi scris at\u00e2t nota, c\u00e2t \u0219i componenta, atunci se poate crea un test automat care s\u0103 verifice adecvarea func\u021bion\u0103rii serviciului cu diferite tipuri de date la intrare. Serviciul \u00eentoarce un cod de r\u0103spuns nerecunoscut \u00een not\u0103? Poate s\u0103 proceseze corect datele evident gre\u0219ite?<\/p>\n

Mai mult dec\u00e2t at\u00e2t, o implementare de calitate nu doar a contractelor, ci \u0219i a instrumentelor pentru vizualizarea notelor permite simplificarea lucrului cu microserviciul. Adic\u0103, dac\u0103 arhitectul a descris cu rigurositate contractul, pe baza acestuia, designerii \u0219i dezvoltatorii vor integra serviciul \u00een alte produse f\u0103r\u0103 cheltuieli de timp suplimentare.<\/p>\n

Pentru func\u021bionarea instrumentelor suplimentare, at\u00e2t RAML, c\u00e2t \u0219i OAS au capacitatea de a ad\u0103uga metadate, neprev\u0103zute de standard (de exemplu, a\u0219a cum se face \u00een OAS<\/a><\/noindex>).<\/p>\n

\u00cen general, c\u00e2mpul pentru creativitate \u00een aplicarea contractelor pentru microservicii este imens\u2026 cel pu\u021bin teoretic<\/p>\n

Compararea ariciului cu \u0219arpele<\/h3>\n

\n\u00cen prezent, direc\u021bia prioritar\u0103 de dezvoltare la Acronis este Acronis Cyber Platform. Acronis Cyber Platform reprezint\u0103 noi puncte de integrare pentru servicii externe cu Acronis Cyber Cloud \u0219i partea agentului. De\u0219i API-urile noastre interne, descrise \u00een RAML, erau satisf\u0103c\u0103toare, necesitatea public\u0103rii API-ului a readus \u00een discu\u021bie alegerea: care standard de anotare ar fi mai bun pentru na\u0219tere?<\/p>\n

Ini\u021bial, p\u0103rea c\u0103 exist\u0103 dou\u0103 solu\u021bii \u2014 cele mai comune dezvolt\u0103ri sunt RAML \u0219i Swagger (sau OAS). Dar, de fapt, s-a dovedit c\u0103 alternativele sunt cel pu\u021bin 2, ba chiar 3 sau mai multe.<\/p>\n

Pe de o parte, exist\u0103 RAML \u2014 un limbaj puternic \u0219i eficient. Acesta are o ierarhie \u0219i mo\u0219tenire bine implementate, astfel \u00eenc\u00e2t acest format se potrive\u0219te mai bine companiilor mari, care necesit\u0103 multe descrieri \u2014 adic\u0103 nu un singur produs, ci multe microservicii care au p\u0103r\u021bi comune ale contractelor \u2014 scheme de autentificare, tipuri de date identice, corpuri de erori.<\/p>\n

Dar dezvoltatorul RAML, compania Mulesoft, s-a al\u0103turat consor\u021biului Open API, care se ocup\u0103 cu evolu\u021bia Swagger<\/a><\/noindex>. A\u0219adar, RAML \u0219i-a oprit dezvoltarea. Pentru a-\u021bi imagina formatul evenimentului, imagineaz\u0103-\u021bi c\u0103 mentenanii componentelor de baz\u0103 Linux au plecat s\u0103 lucreze la Microsoft. Aceast\u0103 situa\u021bie creeaz\u0103 premisele pentru utilizarea Swagger, care se dezvolt\u0103 dinamic \u0219i, \u00een ultima \u2014 a treia versiune \u2014 aproape ajunge la RAML \u00een ceea ce prive\u0219te flexibilitatea \u0219i func\u021bionalitatea.<\/p>\n

Dac\u0103 nu ar fi un aspect\u2026<\/h3>\n

\nDup\u0103 cum s-a dovedit, nu toate utilitarele open-source s-au actualizat la versiunea OAS 3.0. Pentru microservicii pe Go, lipsa adapt\u0103rii go-swagger<\/a><\/noindex> la noua versiune a standardului va fi cea mai critic\u0103. Totu\u0219i, diferen\u021ba dintre Swagger 2 \u0219i Swagger 3 este imens\u0103<\/a><\/noindex>. De exemplu, \u00een a treia versiune, dezvoltatorii:<\/p>\n