W ostatnim czasie ciężko przeoczyć dumne nagłówki krzyczące o kolejnych RESTfulowych aplikacjach czy frameworkach. Zapewne zastanawiasz się, czy możesz wpleść styl REST (Representational State Transfer) w swoją aplikację i jakie będą tego wymierne korzyści? Odpowiedź na pierwsze pytanie brzmi – oczywiście, ale raczej tylko wtedy, gdy Twoja aplikacja otwiera się na świat dzięki zewnetrznemu API. Dostosowując je do tego stylu z pewnością ułatwisz pracę programistom chcącym wnieść coś do Twojego projektu.
REST to spis rygorystycznych wymagań mający na celu nieco zjednolicić i usprawnić komunikację między usługami sieciowymi i klientem. I aby coś było zgodne ze stylem REST wszystkie kryteria muszą zostać spełnione.
- Podział na warstwy klient-serwer
W aplikacjach PHP raczej nic niezwykłego. Myślę, że nie trzeba się nad tym dłużej rozwodzić, bez spełnienia tego warunku cała reszta nie ma sensu.
- Bezstanowość
Protokół HTTP w swoich założeniach jest bezstanowy (każde żądanie jest autonomiczne i nie zawiera informacji o wcześniejszych poczynaniach użytkownika), nie można jednak tego powiedzieć o ciasteczkach i sesjach.
Nie jest to jednak przeszkodą we wszystkich produkcjach wymagających utożsamienia użytkownika. W wypadku sklepu internetowego dane użytkownika mogą zostać przekazane serwerowi dopiero po naciśnięciu przycisku „realizuj zamówienie” które za jednym zamachem prześle dane o zamawianych towarach (zbierane na przykład za pomocą Java Scriptu) a w authentication headers dane identyfikujące klienta. I chociaż może się wydawać, że zbieranie danych z różnych podstron za pomocą skryptu po stronie użytkownika narusza pewną bezstanowość to tak naprawdę liczy się tylko ostatnie żądanie, wykonujące zamówienie. A jest ono w pełni autonomiczne, przekazuje WSZYSTKIE wymagane informacje do obsłużenia klienta, nieważne skąd pochodzą.
Nie wiem czy to widać, ale to ujednolica API różnych usług sieciowych. Dzięki temu inna aplikacja będzie w stanie wysyłając odpowiednie żądanie wykonać to samo, co nasz frontend znudowany z HTML i Java Script.
- Cache
Punkt niby oczywisty. Serwer zwracając wynik żądania powinien poinformować klienta W JAKI sposób przechowywać otrzymane dane, co może później wykorzystać obniżając ruch w sieci. A druga strona, korzystająca z Twojego API powinna ten zapis uszanować.
- Międzymordzie (interfejs znaczy się)
RESTfulowe API korzystają ze znanych od dawna, szeroko rozpowszechnionych formatów danych takich jak HTML, XML czy JSON. Obsługa odbywa się za pomocą czterech typów żądań HTTP: metod GET (pobieranie), PUT (dodawanie), DELETE (usuwanie) i POST (edycja). PUT i DELETE zazwyczaj są emulowane i przesyłane metodą POST na przykład z parametrem _method=PUT/DELETE
- Zasoby
Najważniejsza kwestia i główna składowa stylu REST. Inaczej adres/rzeczownik (OK, po polsku znowu głupio zabrzmiało, ang. noun).
Koncepcję zasobów można przyrównać do klas w PHP. Pojedynczy zasób posiada swój unikalny identyfikator, tak samo jak mamy identyfikatory obiektów zapisanych w pamięci. Jeżeli coś ma swoje unikalne ID i jest dostępne dla świata zewnętrznego – jest zasobem.
Przykładowe odwołanie do zasobu „blog_post” o identyfikatorze 123: http://example.com/blog_post/123, a lista wszystkich zasobów tego typu: http://example.com/blog_post. Nic nie stoi na przeszkodzie aby dodać np. parametr limit w taki: http://example.com/blog_post?limit=10 lub inny sposób.
- Reprezentacje
Serwer nigdy nie zwraca zawartości swojej bazy danych w nieobrobionej postaci. Zamiast tego korzysta z wielu ustalonych wcześniej standardów takich jak XML, JSON, GIF, PNG, JPEG… Możemy więc otrzymać wynik z różnym
MIMEInternet media type, bardzo często mając nawet możliwość wyboru jaki format danych preferujemy. Na przykład dopisując po rozszerzenie do URI. Różne formaty danych jednego zasobu to jego różne reprezentacje - Linki/powiązania
Z angielska hypermedia. W RESTfulowej usłudze zasoby powinny być powiązane ze sobą. I tak, w prosty sposób używajac metody GET i URI /blog_post/123/comments dostaniemy listę komentarzy (zasób komentarzy) powiązanych z zasobem blog_post o identyfikatorze 123. Chcąc dodać nowy komentarz wywołamy metodę PUT z adresem /blog_post/123/comments przesyłając dane o nowym komentarzu (autor, treść…).
- Metadata
To dane mogące dotyczyć zarówno zasobu lub jego reprezentacji. Są to informacje takie jak długość zwróconych danych, kodowanie, formacie, wskazówki co do sposobu przechowywania cache… Wszystko co może interesować programistę powinno zostać zwrócone ZA KAŻDYM RAZEM wraz z danymi zasobu. Na przykład w nagłówkach HTTP.
- Zasoby
- Warstwy
Bardzo często pomijany punkt którego brak równie często zabija lwią część zalet RESTfulowego stylu. Twoja aplikacja powinna umożliwiać poszczególnym warstwom sieciowym (serwerom pośredniczącym, routerom) przechowywać otrzymane informacje ułatwiając cache’owanie i równomierne rozłożenie obciążenia.
- Code-on-demand (opcjonalne)
To co wspomniałem w punkcie „bezstanowości”. REST zakłada przesyłanie użytkownikowi dodatkowego kodu do wykonania po stronie klienta, z czego wszelkie operacje wymagające używania bądź zapisania pewnego stanu powinny skorzystać. Może to być znany duet HTML-JS, Flash, itp.
Podsumowanie
Przyznam szczerze, że na początku uważałem REST za kolejny zbędny buzzword, jednak jak się okazało styl ten (należy pamiętać, że nie jest to żaden standard tylko pewna dobra praktyka) naprawdę porządkuje podejście do tworzenia zewnętrznego API, co myślę ma bardzo dobry wpływ na powstawanie środowiska programistów skupionych wokół Twojej aplikacji. A to ma niemal zawsze pozytywne przełożenie. Z racji jednak tego, że również w temacie jestem dość nowy mogłem coś pokręcić za co serdecznie przepraszam i proszę o poprawki w komentarzach.
Na zakończenie chciałbym jeszcze zachęcić Was do eksperymentowania ze specyfikacją, na przykład, w miarę popularnego w Polsce serwisu mikroblogowego Blip (oczywiście nie tak popularnego jak Twitter). Specyfikacja dostępna na stronie Blipa, wśród przykładów można znaleźc przykładowe komendy curla do wpisania w terminalu. Naprawdę polecam się im przyjżeć i pokombinować.
Bardzo doby artykuł, dzięki.
Jak użytkownik wyłączy JavaScript, to całe zamówienie szlak trafi ;].
To tylko przykład, nikt nas nie zmusza do budowania strony w oparciu o bezstanowy model. Jednak zewnętrzne API już jak najbardziej.
to ma być artykuł techniczny, pisz językiem technicznym