API dobre na wszystko – korzystanie z narzędzia SWAGGER   Leave a comment

Można powiedzieć, że sercem nowoczesnych aplikacji jest jej API czyli zbiór reguł do wywołania funkcjonalności udostępnionych na zewnątrz. Tutaj też zaczyna rosnąć w znaczenie sposób dzielenia aplikacji na komponenty (zamiast zwartego system tzw. architektury silosowej) dostępnych przez mikroserwisy, które są lokalnym API. API w świecie aplikacji rozproszonych, podzielonych na komponenty i korzystających z SOA – staje się niejako wizytówką aplikacji. Dobrze przemyślana struktura API zwiększa konkurencyjność aplikacji. Na podstawie artykułu – http://www.infoworld.com/article/2902750/application-development/manage-apis-with-swagger.html. Swagger jest jednym z narzędzi do tworzenia, testowania i dokumentowania API w aplikacjach. API Swaggera bazuje na koncepcji Restful oraz zasobów URI.

Podobny artykuł z O’Reilly – http://radar.oreilly.com/2015/09/building-apis-with-swagger.html. Odwieczny dylemat co pierwsze API czy kod? Wygląda na to, że API ma być pierwsze – tak wybrała firma Apigee, pionier w tym podejściu. Mamy tu interakcję między zespołem tworzącym API a deweloperami – należało zapewnić między nimi sprawny obieg. Zaczęto mówić o potrzebie narzędzia do zarządzania cyklem życia API. Tak powstało narzędzie Swagger (stworzone przez firmę Reverb) wymyślony przez nich format przedstawienia API. Każde API ma swój zasób URI.

Istniejące do powstania Swaggera rozwiązania API można podzielić na dwie kategorie:

  1. API generuje kod – poprzez wykorzystania języka IDL jak SOAP, CORBA, RCP. Interfejs (API) jest zdefiniowany w odrębnym pliku na podstawie którego generowany jest kod serwera i klienta. Wadą jest konieczność zapewnienia narzędzia do synchronizacji zmian w pliku API i regenerowanie kodu (typowe zajęcie dla CLI).
  2. Kod aplikacji określa API – poprzez stosowanie adnotacji jak w Javie (np. w JAXRS czy pierwotnej implementacji Swaggera. Kod i API są zawsze aktualne, ale opis API jest rozwlekły, niezrozumiały i nie do wykorzystania poza programistami
  3. Powstało też trzecie podejście kod jest równoważny z API – dla aplikacji bazujących na node.js stworzono frameworki np. express.js gdzie kod (funkcje) są przypisane bezpośrednio do URI (jedna z cech notacji funkcji w JS). Wada – wciąż brak możliwości generowania dokumentacji oraz nadal jest mieszanka kodu z opisem API.
  4. Bazując na powyższych doświadczeniach Swagger zastosował podejście projektowanie API steruje generowaniem kodu – zaowocowało to w następujących cechach:
    1. API tworzy się najpierw
    2. Artefakty opisujące konstrukcję API sterują generowanie kodu w czasie wykonania
    3. Zmiana w projekcie API będzie w czasie rzeczywistym wspierana w sposób przeźroczysty  w narzędziu (tak, że zniknie niebezpieczeństwo rozsynchronizowania się kodu lub dokumentacji)

Dodatkowo format Swagger 2.0 pozwala na dodatkową adnotację np. ze specyfikacją autoryzacji

Posted 8 Październik 2015 by marekwmsdn in JavaScript, Swagger

Tagged with , ,

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s

%d bloggers like this: