SOAP w erze REST API

 In Technicznie

Implementując API, warto przeanalizować technologie, które pozwolą stworzyć rozwiązanie, jakiego potrzebujemy. W tym wpisie skupię się na dwóch popularnych możliwościach. Są to REST oraz SOAP. Dowiesz się, czym są te technologie, jakie mają zastosowanie oraz którą z nich lepiej wybrać.

Czym jest…

SOAP

SOAP (Simple Object Access Protocol) jest protokołem komunikacyjnym, który wykorzystuje XML do zapytań. Do przesyłania informacji może wykorzystać między innymi takie protokoły jak: HTTP, HTTPS, SMTP. Został stworzony w 1998 roku przez grupę osób przy współpracy z Microsoft. Obecnie jest standardem W3C.

SOAP musi być zgodny z pewnymi charakterystykami, aby komunikacja pomiędzy obiektami była zgodna:

  • Protokół jest rozszerzalny — rozszerzenia do podstawowych funkcjonalności mogą być tworzone i używane bez oddziaływania podstawowych funkcjonalności.
  • Zawartość wiadomości powinna być niezależna od protokołu, którym jest przesyłana — dane mogą być przesłane przy użyciu różnych protokoły do transportu danych.
  • Protokół powinien być oddzielony od fundamentalnego modelu programowania — programiści powinni mieć możliwość rozwoju serwerów i klientów SOAP bez restrykcji ze strony logiki bądź filozofii projektu.

REST

REST (Representational State Transfer) jest stylem architektury oprogramowania, który definiuje zbiór zasad używanych do tworzenia web serwisów. Do przesyłania informacji najczęściej wykorzystuje JSON, ale nie jest to zasadą. Został stworzony w 2000 roku przez Roya Fieldinga.

REST może być także opisany jako kierunek budowania web serwisów, przestrzegając zasad obowiązujących pomiędzy dostawcami a klientami:

  • Separacja odpowiedzialności pomiędzy klientem i serwerem — elementy te nie powinny mieszać swoich odpowiedzialności. Dla przykładu serwer nie powinien interesować się interfejsami użytkownika, natomiast klient nie powinien zajmować się przechowywaniem danych. Pozwala to na skalowanie rozwiązania.
  • Komunikacja pomiędzy klientem i serwerem musi być niezależna od stanu — serwery nie powinny przechowywać informacji na temat kontekstu klientów pomiędzy zapytaniami.
  • Klient powinien mieć możliwość zapisywania odpowiedzi do pamięci podręcznej — dzięki temu klient może decydować czy rzeczywiście wymagane jest skierowanie żądania do serwera o dane (może je już posiadać).
  • Połączenie powinno mieć miejsce na kilku warstwach komunikacji — klient nie powinien rozróżniać czy jest podłączony do serwera bezpośrednio, czy poprzez pośrednika. Pozwala to na wykorzystanie Proxy oraz równych metod skalowania.

Zastosowanie

SOAP i REST wykorzystuje się do komunikacji pomiędzy klientem i serwerem. Są zatem obecne w większości aplikacji. Zapewniają wymianę informacji pomiędzy aplikacją kliencką (obsługiwanej przez użytkownika) i serwerem (dostarczającym danych). Z perspektywy programisty różnią się głównie sposobem, w jaki informacje mają być przesyłane.

Co wybrać?

Jeżeli tworzysz proste API to tylko i wyłącznie REST. Pozwoli Ci to na skupienie się na operacjach, które potrzebujesz wykonać na wybranym zasobie. Ponadto dużo prościej znaleźć w sieci informacje na temat REST, a co za tym idzie także rozwiązań popularnych problemów. REST jest także wykorzystywany w wielu projektach open source. Wzorzec ten będzie dobrym wyborem do wykorzystania w aplikacji mobilnej, ponieważ mniej obciąża łącze.

Czy zatem SOAP jeszcze jest potrzebny? Oczywiście!

SOAP natomiast sprawdzi się w sytuacji, gdy wymagana będzie duża restrykcja dotycząca zapytań. Z uwagi na ten aspekt SOAP jest bardzo często wykorzystywany w aplikacjach na poziomie enterprise. Protokół ten wymaga także przesłania kompletnych obiektów, co wiąże się z wyższym wykorzystaniem łącza. Z tego powodu odradza się wykorzystywania SOAP w aplikacjach mobilnych.

Recent Posts