wtorek, 4 lutego 2014

REST i okolice - chaper 1


REST = REpresentation State Transfer
REST in a nutshell to : 'RE' zasoby reprezentowane w każdej możliwej formie , 'T' = umożliwia transfer zasobów z jednej aplikacji do drugiej, 'S' - koncentrujemy się na zasobie a nie na działaniu (WS)
REST to również styl architektoniczny, którego autorem jest koleś współtworzący protokół HTTP czyli Roya T. Fieldinga . Można się spodziewać, że w takim razie wiedział on co robi tworząc REST.
Podstawowym komponentem jest zasób (resource), który jest adresowany poprzez URI.
W dzisiejszych czasach każdy poważny serwis internetowy udostępnia API. Więc czemu się na tym nie wzorować ? W przeciwieństwie do standardowych WS pozbawiony jest często niepotrzebnej otoczki jaką jest SOAP i działa! - poprzez efektywne wykorzystanie HTTP. Bardzo fajnie sprawdza się w aplikacjach mobilnych, ze względu na swoją 'lekkość'.


Ale zawsze jest coś za coś.... Nie ma róży bez kolców.
Standardowy WS wybieram zawsze tam gdzie potrzebuje wyrafinowanego security (WS-Security),
walidacji, routingu, gwarancji dostarczenia czy wysokiej niezawodności.
Generalnie pewnie lepiej sprawdzi się w aplikacjach korporacyjnych.
WS oparty na SOAP można tworzyć na 2 sposoby :
  - Bottom-Up czyli najpierw tworzymy klasy domenowe oraz klasy serwisu
  - Top-Down - punktem wyjścia jest istniejący już plik WSDL opisujący usługę.     

TIP: SOAPUI - testuj REST i WS zarazem

REST daje mi nowe możliwości w tworzeniu publicznego API na wzór wyżej wspomnianych portali czy serwisów internetowych.
Widzieliście już wcześniej API Facebooka czy Twittera.
Są świetne. Warto się na nich wzorować. Wiele firm buduje na podstawie tego API usługi dodane (value-added services) zwane mashupami.
Jest to serwis, który w celu stworzenia nowych usług wykorzystuje i łączy ze sobą dane pochodzące z co najmniej dwóch źródeł. Cechą mashup'a jest agregacja i wizualizacja. Przetworzone w ten sposób dane mają stać się bardziej przydatne.



Co więcej proponuje pisać od samego początku aplikacje w stylu REST. Dzięki temu nie obchodzi mnie wcale warstwa prezentacji bo zawsze mogą ją podmienić na inną (MVC) a dane ciągnę sobie poprzez AJAX.
Mało tego dostaje od razu dostęp do danych poprzez HTTP, bez użycia przeglądarki czyli usługę WS.

Tip : Poster, HttpRequester, RestClient firefox plugins 
Tip : Rest-shell - polecam ....
Tip : CURL przykład :
curl -H "Accept: application/json" -i http://localhost:8080/api/tags/1



Teraz inne aplikacje mogą gadać ze sobą poprzez takie API.
Wniosek jest następujący dostajemy łatwość integracji oraz bardziej elastyczny system. Dostęp do danych będzie bardziej intuicyjny, a dane zwracane mogą być w różnym formacie od json'a, xml'a po swoje własne egzotyczne formaty.

REST wspomaga ogólną wydajność bo łatwo się cache'uje oraz zyskuję trochę na przepustowości łącza.
Zalet jest więcej. Ważne jest aby pisać RESTful, a nie RESTless bo wtedy przygotowujemy sobie dwie pieczenie przy jednym ogniu.

OK.

REST – to obecnie bardzo popularne usługi internetowe
WS – bardziej wykorzystywanie w usługach aplikacji enterprise wymagających zapewnienia wysokiej jakości (QoS)
WS – wyższe standardy zabezpieczeń, walidacji, routingu, niezawodności
REST – skalowalność, prostota architektury, łatwość użytkowania oraz integracji.

REST to także :
System warstwowy  - w której każda warstwa może mieć tylko jeden poziom poniżej. Promocja prostoty.
Klient/Serwer - rozdzielenie klienta i dostawcy
Komunikacja bezstanowa  - warunek dobrej skalowalności
Replikowane repozytorium -można dostarczać określoną usługę za pomocą więcej niż jednego procesu = dostarcza skalowalność (scalability) i dostępność (HA)
Buforowanie = cache - komunikaty same określają jak i kiedy i ile czasu możemy buforować je w pamięci. Czyli otrzymujemy redukcję obciążenia serwera przez dostajemy większą wydajność.

Jednolity interfejs - 8 metod (PUT,POST,GET,DELETE,OPTIONS,HEAD,TRACE,CONNECT)


Teraz ważne jest zrozumienie terminów metoda: bezpieczna i idempotentna.
Metoda bezpieczna nie zmienia stanu zasobu.  
Metoda idempotentna może zmieniać stan lub nie, ale każde dalsze wywołanie takiej metody nie powinno powodować dalszych skutków. Wszystkie bezpieczne metody są idempotentne, ale nie wszystkie idempotentne są bezpieczne.

HATEOAS (Hypermedia as the Engine of Application State) - czyli zastosowanie "hipermediów jako silnika stanu aplikacji". Rozwiązanie to dostarcza linki do kolejnych zasobów powiązach logicznie czy biznesowo z obecnym bytem. Zajebiste ;)
Albo inaczej używając HATEOAS dostajesz samo opisujące się API.
Co jest dla mnie bardzo ważne poprzez HATEOAS możemy nawigować po aplikacji bez żadnego interfejsu użytkownika.

Dojrzałość serwisu REST ocenimy na podstawie tzn modelu dojrzałości Richardsona.

Ale po cholerę mi ten model ? Odpowiadam Ci, że  po to abyś ocenił ile Twój serwis jest RESTful a ile Restless.



























WS SOAP - również preferuje model bezstanowy, a buforowalność możemy osiągnąć na jednej z niższe z warstw np serwisie.
WS pozwala tworzyć reużywalne elementy.

Można wzbogacić SOA poprzez REST ? - tak : 
 - budowanie usług REST i poszerzanie ich tak aby stały się SOA.
 - poszerzanie usług SOA tak aby stały się usługami RESTful.

TIP : Wzorzec komponent brzegowy, CAMEL

Security : 
W WS podniesienie poziomu bezpieczeństwa uzyskujemy po przez użycie SSL czy użycie WS-Security.
Dla REST istnieje podejście alternatywne zwane OAuth czy OAuth2.
WS-Security jak i OAuth wykorzystuje tokeny w procesie autoryzacji.

Rozwinięcie problemu zabezpieczenia serwisów REST i WS znajdziesz niebawem tutaj

REST posiada znakomite wsparcie od Spring 3 w górę :

RestTemplate unikamy 'code boilerplate' i skupiamy się na rzeczach ważnych dla biznesu aplikacji. Oraz upraszczamy do minimum konsumpcje komunikatów REST.
 


Używając springa wykorzystujemy HiddenHttpMethodFilter do obsługi żądań różnych od GET i POST.



Klienta wywołuje również prosto :






































W konwersji @ResponseBody wiadomości type MiME pomogą konwertery:
























Ogólne zasady programowania serwisów REST są następujące :

Zwracamy odpowiedni status kodu w zależności od odpowiedzi :


Znaczenie kodów nagłówka HTTP : 
200 OK - żądanie zrealizowane prawidłowo

201 Created - zwraca Location header dla nowo stworzonego zasobu

202 Accepted - serwer zaakceptował żadanie, ale nie jest ono jeszcze kompletne.


301 Moved Permanently / 302 Move Temporarily - zasób przeniesiono w inne miejsce. Nowe położenie zasobu znajdziesz z nagłówku Location w ramach response.

304 - Not Modified - żądany zasób nie był zmodyfikowany od czasu poprzedniego żądania (sprawdzanie za pomocą nagłówka IF-Modified-Since)

401 Unauthorized - klient nie ma uprawnień by dobrać się do żądanego zasobu. W odpowiedzi powinna znaleźć się informacja dlaczego tak się stało (nagłówek WWW-Authenticate)

403 Forbidden - klient nie ma uprawnień niezbędnych do uzyskania dostępu do danego zasobu. Inaczej jak w przypadku instrukcji 401 odpowiedź nie zawiera żadnych informacji na temat uwierzytelnienia.

404 Not Found - nie można znaleźć zasobu.

406 Incompatible - nie kompatybilny nagłówek (Accept)

409 Conflict - konflikt zasobów podczas próby dostania się do zasobu przez klienta

500 Internal Server Error  - serwer nie może z jakiś powodów zrealizować danego żądania


Projektujemy API :







































Tip : Content negotiation - porozumienie się jeśli chodzi o  reprezentacje zasobu
Client - > Accept header
Server -> Content-Type header

Tip : Zawsze zwracaj czytelny komunikat błędu.

Tip :@ControllerAdvice - pomoże Ci globalnie lub generycznie obsługiwać sytuacje wyjątkowe.

Tip : SSL - zapobiega atakowi man-in-the-middle

Kod do aplikacji znajdziesz niebawem tutaj

P.S Ten post rozpoczyna jeden z moich ulubionych problemów i tematyk. Będzie ewoluował jeszcze przez jakiś czas. Czekajcie na kody na GitHubie. Oraz kolejne wersje, które wprowadzą Was także w świat i wzorce SOA od kuchni.

REST API part 2 ->

Brak komentarzy:

Prześlij komentarz