1. REST - small introduction

Co to jest REST?
Na DevDeys 2010 Aaron Skonnard prowadził prezentację Why we need some REST?. To będzie małe streszczenie z moimi przemyśleniami i zapewne ogromnym chaosem myśli (za który przepraszam).

/* Ten post powstawał baardzoo długo i mam nadzieje że przerodzi się w kompletny cykl, a być może i więcej. Wszystkie spostrzeżenia i naprostowania mnie na właściwą drogę mile widziane ;) */

Zanim przejdziemy do głównego tematu - REST spójrzmy na znacznie bardziej obecnie znany standard SOAP (Simple Object Access Protocol):
Dobre strony SOAP: standaryzacja, service metadata, szeroki wachlarz narzędzi. SOAP operuje na wiadomościach XML wysyłanych do zdefiniowanego punktu końcowego (endpoint). Serwis odbierający wiadomość decyduje się co dalej zrobić na podstawie akcji zawartej w nagłówku - według standardu WS-Addressing. Wiadomości XML wysyłane przez HTTP zawsze będą używać metody POST, właściwie SOAP nie potrzebuje do szczęścia nic innego. WSDL opisuje endpointy zawiera wszystkie operacje które może wysłać i odebrać. Ponieważ zawsze używana jest metoda POST nie możliwe jest korzystanie z mechanizmu Cashing i każda wiadomość podróżuje zawsze od web serwera aż do endpoint.
Yachoo, Amazon i Google (Google na początku było zbudowane na SOAP) nie używają SOAP, głównie we względu na duże zróżnicowanie odbiorców.

Więc co to jest REST?
Representational State Transfer - termin przedstawiony w roku 2000 przez jednego z głównych twórców protokołu HTTP Roya Fieldinga w jego pracy doktoranckiej. REST określa model, zasady umożliwiające budowanie rozwiązań (network architecture) które pozwalają na bardzo dużą skalowalność sieci (i własnych rozwiązań). Model ten to zasób (obiekt/Resource) + reprezentujący go URI. Lub z drugiej strony - każdy URI wskazuje na jakiś obiekt.
Ponieważ każdy zasób reprezentowany jest przez oddzielny URL nie ma takiej konieczności aby wszystkie zasoby znajdowały się w tym samym miejscu. Każdy zasób (lub dowolny podzbiór) może znajdować się na innym hoście. Rest oprócz zasobów reprezentowanych przez Uri to również kwestia reprezentacji - dany zasób może być reprezentowany jako wynik typu XML, Json, Image i inne.
Można więc w wielkim skrócie powiedzieć:
REST = zasób + reprezentacja
Do tej pory Microsoft wydaje się że mocno stawiał na architekturę SOAP pomijając z lekka REST. SOAP jest zorientowany na obiekty i może transportować dane przez wiele protokołów. Dodatkowo istnieje cała masa mechanizmów rozszerzających funkcjonalność SOAP a wszystkie z przedrostkami WS, które nie są dostępne dla HTTP. REST działa bardziej jak sam HTTP i wykorzystuje jego całą moc.
SOAP i REST to dwie różne drogi.

Microsoft opanował się dopiero przy .NET 3.5 i udostępnił pierwsze implementacje RESTa abyśmy my programiści mogli iść dowolnie wybraną ścieżką. W końcu nie ma idealnego rozwiązania/technologii/architektury do wszystkiego (jak coś jest do wszystkiego to jest...). WCF przedstawił WebRequest w Rest Toolkit.
Na pewno SOAP będzie wykorzystywany w wielu aplikacjach, jednak jeśli potrzebny jest wam serwis udostępniający dane poprzez internet, który może się rozrastać i który będzie miał wielu odbiorców - to zapewne REST będzie lepszy. (w kierunku chmur to chyba jedyna droga).

REST	SOAP
Bezstanowy	Może być stanowy
Nie wspiera transakcji	Wspiera transakcje
"Transfer specific" czyli zawsze używamy HTTP. Znaczy to że zawsze przesyłamy dane tekstowe - więc wysyłamy je powoli, ale możemy dostać się np za Firewall	Może używać różnych standardów transportu. np wewnątrz sieci może posługiwać się TCP, jeśli ograniczymy się do jednej maszyny może korzystać z IPC. Dzięki temu może być bardzo szybki.
Bardzo interoperacyjny (interoperable)	Interoperacyjny ale tylko w zakresie bindingu (transportu), odbiorca musi rozumieć dany standard wysyłanych danych co nie zawsze jest łatwe (np w iPhonach)
Zawsze posługuje się interfacem GET POST PUT DELETE - czyli CRUD w najczystszej postaci	Nie przejmuje się HTTP, zawsze używa POST oraz swoich standardów (WSDL, WS*)
słabo typowany	silnie typowany w oparciu o kontrakt
nastawienie na zasoby	nastawienie na operacje
Bardzo czytelne wiadomości, niewielki narzut do wielkości wiadomości. Każdy klient HTTP powinien sobie poradzić z odczytaniem wiadomości	Skomplikowane i zawsze obudowane wiadomości. Wymaga wiedzy i narzędzi do otworzenia/odebrania wiadomości.
Zasoby/obiekty identyfikowane są przez URL (sieć to graf połączonych zasobów) jeśli tylko restrykcje biznesowe na to pozwalają zawsze można powrócić do bieżącego URL	Operacje wykonywane są w sekwencji i nie zawsze da się powrócić do każdego/dowolnego punktu
ograniczone możliwości zabezpieczania (security)	wspiera wiele modeli zabezpieczeń

Dlaczego REST

• Większość ludzi nie potrzebuje kluczowych funkcji SOAP czyli neutralności warstwy transportu oraz zaawansowanych protokołów WS
• REST jest prosty , ujednolicony (uniform) i composable ->
  nie umiem znaleźć ładnego słowa kojarzą mi się tylko klocki Lego - każdy do każdego pasuje, każdy można wymienić na inny a budować można duże konstrukcje, i każdy wie jak budować z klocków Lego - dokładnie tego porównania używają również prelegenci opowiadający o REST. Interface jest jeden i jest prosty i wszyscy go znają – co nie ogranicza nas w tworzeniu skomplikowanych rozwiązań.
  A przynajmniej taka jest teoria bo jak pierwszy raz siada się do RESTa – do konsumpcji - człowiek jest zagubiony nie ma web referencji, nie ma klasy proxy – I co tu zrobić.Interakcja z HTTP wydaje się być tabu – tego nie powinno się robić - takie wrażenie zostaje po latach używania mydła.Samo to nie przychodzi do głowy
• REST zapewnia szerszy zasięg (choćby iPhony Androidy...)
• REST działa tak jak internet i korzysta z wbudowanych mechanizmów takich jak caching, bookmarking, linki, SSL, dostępność przez przeglądarki internetowe.

Czemu SOAP?

• Przywykliśmy
• zabezpieczenia(wbudowane)
• tranzakcyjność
• W pewnych zastosowaniach jest szybszy
• zapewne lepiej sprawdzi się w bardzo dużych rozwiązaniach za firewallem

WCF praktycznie od samego początku REST StarterKit podobnież miał być częścią kolejnego frameworka, jednak na konferencji MIX11 ogłoszono preview WCF Web Api, które jest następcą StarterKita, ale o tym w kolejnych postach.

•Na podstawie: Why REST? by Aaron Skonnard 15.04.2010