Wstęp
REST (ang. REpresentational State Transfer) – styl architektoniczny oprogramowania wprowadzony i zdefiniowany w 2000 roku przez Roya Fieldinga w jego rozprawie doktorskiej, którą można znaleźć pod adresem: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm. Autor wymienia sześć ograniczeń, na których opiera się architektura REST:
- jednorodny interfejs (ang. uniform interface),
- bezstanowość (ang. stateless),
- pamięć podręczna (ang. cache),
- klient-serwer (ang. client-server),
- system warstwowy (ang. layered system),
- kod na żądanie (ang. code on demand).
REST nie jest standardem, jak już wspomniałem wcześniej podstawą jest sześć wyżej wymienionych ograniczeń. Jednak rozwiązania oparte o architekturę REST przez cały czas ewoluują, pojawiają się dodatkowe kryteria i rozwiązania. Według mnie jeżeli rozpatrujemy wykorzystanie w naszym rozwiązaniu architektury REST to należy brać pod uwagę następujące cechy:
- model klient-serwer, gdzie klient to właściwie dowolna aplikacja (desktop, mobilna, działająca w przeglądarce internetowej), która jest w stanie za pomocą metod http (GET, POST, PUT, DELETE, OPTIONS, HEAD) uzyskać dostęp do zasobów serwera. Zasoby w ramach serwera udostępniane są przez serwisy REST,
- dostęp do zasobów serwera odbywa się przez URL,
- dane pomiędzy klientem a serwerem przesyłane są przez tzw. obiekty danych reprezentowane przez najczęściej XML lub JSON,
- komunikacja pomiędzy klientem a serwerem jest bezstanowa, co oznacza, że każde odpytanie serwisu REST ze strony klienta jest traktowane jako niezależna (od poprzednich odpytań) transakcja. Serwis REST nie utrzymuje danych związanych z poszczególnymi odpytaniami przez klienta - mówimy tutaj o braku utrzymania stanu konwersacji pomiędzy poszczególnymi wywołaniami serwisu. Takie rozwiązanie posiada zalety jak również i wady. Do największych wad zalicza się to, że klient chcąc uzyskać dane od serwisu REST musi wysłać w swoim pojedynczym (każdorazowym) żądaniu komplet potrzebnych informacji do tego aby serwer zwrócił oczekiwany rezultat (zasób). Jeżeli istnieje potrzeba zapamiętania stanu konwersacji, należy zadbać o to poprzez implementację odpowiedniej logiki po stronie aplikacji klienta,
- skalowalność - ponieważ komunikacja pomiędzy klientem a serwerem jest bezstanowa, serwery nie muszą utrzymywać stanu konwersacji z klientem, nie muszą również wymieniać między sobą danych sesyjnych,
- wydajność,
- prostota,
- modyfikowalność.
Prostota REST sprawia, że wytwarzając aplikacje oparte o REST projektanci i deweloperzy skupiają się raczej na aspekcie funkcjonalnym rozwiązania niż na zagadnieniach technologicznych.
Możliwości zastosowania i prostota REST sprawiła, że styl ten stał się alternatywą dla rozwiązań opartych na SOAP (ang. Simple Object Access Protocol).
Implementacja
Jeżeli chodzi o możliwości implementacji aplikacji opartych na REST to istnieje ich co najmniej kilka. Do najbardziej popularnych zalicza się rozwiązania
- JAX-RS – standard wchodzący w skład JEE
- Spring
