Komunikacja między systemami często jest realizowana poprzez wywoływanie zdalnych serwisów. W ostatnim czasie coraz częściej przy budowanie systemów odchodzi się od tradycyjnych web serwisów opartych na technologii SOAP i stosuje się tzw. serwisy REST (RESTful). Terminy REST czy RESTful są obecnie tak często stosowane i nie zawsze poprawnie w kontekście opisywanych serwisów, że warto zapoznać się czym tak naprawdę jest REST i co charakteryzuje serwisy opartej o tej architekturze.
REST jest zbiorem reguł i dobrych praktyk budowania serwisów webowych wykorzystujących protokół HTTP. Innymi słowy REST można określić jako styl architektoniczny opisywany sześcioma warunkami:
1 – Uniform Interface (jednolity interfejs)
2 – Stateless (bezstanowość)
3 – Cacheable (możliwość cache’owania danych)
4 – Client-Server (model klient-serwer)
5 – Layered System (warstwowość)
6 – Code on Demand (kod na żądanie)
Reguła 1 – Uniform Interface (jednolity interfejs)
Jednolity interfejs do komunikacji między klientem a serwerem, który upraszcza integrację i architekturę budowanych rozwiązań, można opisać 4 zasadami:
– intefejs oparty jest na zasobach – każdy zasób jest dostępnym pod unikalnym URI, jednak sposób jego reprezentacji może być różny i jest niezależny od samego zasobu np. serwer nie wysyła danych w postaci odczytanej bezpośrednio z bazy danych, lecz w formacie XML czy JSON.
– manipulacja zasobami jest realizowana poprzez jego reprezentacje – po otrzymaniu reprezentacji zasobu od serwera, klient (jeśli ma do tego uprawnienia) może modyfikować czy usuwać zasoby.
– komunikaty (odpowiedzi) serwera do klienta są samoopisujące się – każda odpowiedź serwera zawiera informacje jak ją obsłużyć np. poprzez wartość „media type” (inaczej „MIME type”).
– HATEOAS (Hypermedia as the Engine of Application State) – klient wysyłając żądanie do serwera przesyła swój stan, parametry żądania, nagłówki oraz URI zasobu. Serwer dostarcza treść, kod i nagłówki odpowiedzi. Techniczne taka forma komunikacji jest określana jako „hypermedia”. Oprócz powyższego HATEOAS oznacza również, że linki zawarte są w treści odpowiedzi lub nagłówkach.
Reguła 2 – Stateless (bezstanowość)
Bezstanowość w przypadku serwisów REST oznacza, że stan konieczny do obsługi znajduje się w żądaniu klienta (jako część URL, parametr żądania, fragment nagłówka czy samej treści żądania). Zmodyfikowany stan może być przesłany przez serwer do klienta w odpowiedzi, jednak żadna informacja o stanie nie jest przechowywana przez serwer, musi być każdorazowo przesłana przez klienta, jeśli jest ona wymagana do jego obsługi. Innymi słowy w przypadku serwisów REST nie istnieje coś w rodzaju sesji HTTP, dzięki czemu skalowalność serwisów REST jest tak duża, ponieważ nie ma potrzeby zarządzania sesjami klientów.
Reguła 3 – Cacheable (możliwość cache’owania danych)
W świecie WWW odpowiedzi serwera mogą być cache’owalne, dlatego ważne jest, by przy budowie serwisów REST określić czy dana odpowiedz może lub nie być cache’owalna. Z reguły dla operacji odczytu istnieje możliwość cache’owania danych, natomiast dla operacji modyfikacji danych nie zaleca się stosowania takiego mechanizmu. Jednak ze wzgledu na to, że znacznie częściej dane są odczytywane niż modyfikowane, włączenie cache’owania znacznie zwiększa wydajność obsługi żądań klientów.
Reguła 4 – Client-Server (model klient-serwer)
Podział systemu na klientów i serwerów ma szereg zalet. Klient nie musi zarządzać połączeniem do bazy danych czy innych systemów, z którymi serwer się komunikuje. Serwer nie musi znać szczegółów interfejsu użytkownika klienta czy też stanem klienta, co ma znaczenie na skalowalność rozwiązania. Klient i serwer może być budowany w różnych technologiach, przez różne zespoły niezależnie.
Reguła 5 – Layered System (warstwowość)
Warstowa budowa systemu ma wpływ na skalowalność rozwiązania. Klient korzystając z określonego serwisu nie musi wiedzieć, czy komunikujuje się z jakąś warstwą pośrednią, która np. balansuje ruch pomiędzy kilka serwerów.
Reguła 6 – Code on Demand (kod na żądanie)
Opcjonalną regułą jest obsługa przez serwery żądań w taki sposób, że klient może przesłać w określony sposób pewną logikę (kod) do zrealizowania przez serwer. Reguła ta jest jednak opcjonalna, często nie jest konieczne przy budowie serwisu, więc jeśli implementowany serwis tej reguły nie spełnia i jest zgodny z pozostałymi, to można taki serwis nazywać REST.