{"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\/hr\/blog\/administrirovanie\/tak-vse-taki-raml-ili-oas-swagger","title":{"rendered":"Dakle, RAML ili OAS (Swagger)?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

U dinami\u010dnom svijetu mikroservisa mo\u017ee se promijeniti sve \u2014 svaka komponenta mo\u017ee biti prepisana na drugom jeziku, koriste\u0107i razli\u010dite okvire i arhitekturu. Neizmjene trebaju ostati samo ugovori kako bi se moglo komunicirati s mikroservisom na nekoj stalnoj osnovi, neovisno o unutarnjim metamorfozama. Danas \u0107emo govoriti o na\u0161em problemu izbora formata za opisivanje ugovora i podijeliti prona\u0111ene artefakte. <\/p>\n

\"Dakle,
\n<\/a><\/noindex>
\nObjavu je pripremila Anna Melekhova<\/a><\/noindex> i Vladimir Lapatin<\/a><\/noindex> <\/p>\n

Mikroservisi.<\/b> Tijekom razvoja Acronis Cyber Cloud shvatili smo da smo ih neizbje\u017eno morali koristiti. A projektiranje mikroservisa nemogu\u0107e je bez formalizacije ugovora, koji predstavlja su\u010delje mikroservisa.<\/p>\n

Ali kada u proizvodu postoji vi\u0161e od jedne komponente, a razvoj ugovora postaje redovita aktivnost, po\u010dinje\u0161 razmi\u0161ljati o optimizaciji procesa. O\u010digledno je da su\u010delje (ugovor) i implementacija (mikroservis) moraju odgovarati jedno drugome, da razli\u010dite komponente trebaju raditi iste stvari na isti na\u010din i da, bez centraliziranog dono\u0161enja svih tih odluka, svaki tim \u0107e ponovno tro\u0161iti vrijeme na njihovo postizanje. <\/p>\n

\"Dakle,
\nShema mikros servisa Amazon iz tweeta<\/a><\/noindex> Wernera Vogels, CTO Amazon<\/i>
\nU \u010demu se zapravo sastoji dilema? De facto postoje dva na\u010dina interakcije mikroservisa \u2013 HTTP Rest i gRPC od Googlea. Ne \u017eele\u0107i se uklju\u010diti u Googleov tehnolo\u0161ki skup, odabrali smo HTTP Rest. Annotacije za HTTP REST ugovore naj\u010de\u0161\u0107e se opisuju jednim od dva formata: RAML i OAS, koji je ranije bio poznat kao Swagger. Stoga se svaki tim programera suo\u010dava s potrebom da odabere jedan od standarda. No, kako se ispostavilo, donijeti tu odluku mo\u017ee biti jako te\u0161ko.<\/p>\n

Za\u0161to su potrebne anotacije?<\/h3>\n

\nSa\u017eetak je potreban kako bi vanjski korisnik mogao lako razumjeti \u0161to mo\u017ee raditi s va\u0161om uslugom putem njenog HTTP su\u010delja. Drugim rije\u010dima, na osnovnoj razini sa\u017eetak bi trebao sadr\u017eavati barem popis dostupnih resursa, njihove HTTP metode, tijela zahtjeva, nabrojavanje parametara, nazna\u010divanje potrebnih i podr\u017eanih zaglavlja, kao i kodove povratka i formate odgovora. Ekstremno va\u017ean element sa\u017eetka ugovora tako\u0111er je i njihovo verbalno opisivanje (\"\u0161to \u0107e se dogoditi ako dodate ovaj query-parametar u zahtjev?\", \"u kojem \u0107e se slu\u010daju vratiti kod 400?\")<\/p>\n

Ipak, kada se radi o razvoju velikog broja mikroservisa, postoji \u017eelja za dodatnom korist od napisanih sa\u017eetaka. Na primjer, na temelju RAML\/Swaaggera mo\u017ee se generirati i klijentski i serverski kod na velikom broju programskih jezika. Tako\u0111er, mo\u017ee se automatski dobiti dokumentacija za mikroservis i prenijeti je na va\u0161u developer-portalu :).<\/p>\n

\"Dakle,
\nPrimjer strukturiranog opisa ugovora<\/i><\/p>\n

Rje\u0111e se susre\u0107e praksa testiranja mikroservisa na temelju opisa ugovora. Ako ste napisali i sa\u017eetak, i komponentu, mo\u017eete stvoriti automatski test koji provjerava adekvatnost rada usluge s razli\u010ditim tipovima podataka na ulazu. Da li usluga vra\u0107a kod odgovora koji nije opisan u sa\u017eetku? Ho\u0107e li ispravno obraditi namjerno neto\u010dne podatke?<\/p>\n

\u0160tovi\u0161e, kvalitetna implementacija ne samo samih ugovora, ve\u0107 i alata za vizualizaciju sa\u017eetaka omogu\u0107ava pojednostavljenje rada s mikroservisom. Drugim rije\u010dima, ako je arhitekt kvalitetno opisao ugovor, na temelju toga dizajneri i programeri \u0107e integrirati uslugu u druge proizvode bez dodatnih vremenskih tro\u0161kova.<\/p>\n

Za rad dodatnih alata, i RAML i OAS omogu\u0107uju dodavanje metapodataka koji nisu predvi\u0111eni standardom (na primjer, tako se to radi u OAS<\/a><\/noindex>).<\/p>\n

Uglavnom, polje za kreativnost u primjeni ugovora za mikroservise je ogromno... barem teoretski<\/p>\n

Usporedba je\u017ea s u\u017eom<\/h3>\n

\nTrenutno je prioritetna linija razvoja u Acronisu \u2013 razvoj Acronis Cyber Platforme. Acronis Cyber Platforma predstavlja nove to\u010dke integracije vanjskih servisa s Acronis Cyber Cloud i agencijskim dijelom. Iako su nas na\u0161i interni API-ji, opisani u RAML-u, zadovoljili, potreba za objavom API-ja ponovno je pokrenula pitanje izbora: koji standard anotacija najbolje koristiti za na\u0161 rad?<\/p>\n

Prvotno se \u010dinilo da postoje dva rje\u0161enja \u2013 najrasprostranjeniji razvojni standardi RAML i Swagger (ili OAS). No, u stvarnosti se pokazalo da alternativa ima barem ne 2, ve\u0107 3 ili vi\u0161e.<\/p>\n

S jedne strane imamo RAML \u2013 sna\u017ean i u\u010dinkovit jezik. Dobro su implementirane hijerarhije i naslje\u0111ivanje, pa je ovaj format vi\u0161e prikladan za velike tvrtke kojima je potrebno mnogo opisa \u2013 to jest, ne jedan proizvod, ve\u0107 mnoge mikroservise koji imaju zajedni\u010dke dijelove ugovora \u2013 sheme autentikacije, jednake tipove podataka, tijela gre\u0161aka.<\/p>\n

No, razvojnici RAML-a, kompanija Mulesoft, pridru\u017eili su se konzorcijumu Open API koji se bavi razvojem Swagger<\/a><\/noindex>. Stoga je razvoj RAML-a obustavljen. Da zamislite format doga\u0111aja, zamislite da su glavni odr\u017eavatelji komponenti sustava Linux oti\u0161li raditi u Microsoft. Ova situacija stvara pretpostavke za kori\u0161tenje Swaggera, koji se dinami\u010dki razvija i u posljednjoj \u2013 tre\u0107oj verziji \u2013 prakti\u010dki susti\u017ee RAML po fleksibilnosti i funkcionalnosti.<\/p>\n

Da nije jednog ali\u2026<\/h3>\n

\nKako se ispostavilo, daleko ne koriste sve open-source alate verziju OAS 3.0. Za mikroservise na Go-u najkriti\u010dnije \u0107e biti odsustvo prilagodbe go-swagger<\/a><\/noindex> na novu verziju standarda. Razlika izme\u0111u Swagger 2 i Swagger 3 je ogromna.<\/a><\/noindex>Na primjer, u tre\u0107oj verziji, programeri su:<\/p>\n