Podejscia do realizacji Web Services

Transkrypt

Podejscia do realizacji Web Services
Podejścia do realizacji Web Services
czyli: Giving SOAP a REST
Piotr Domagalski
[email protected]
16 kwietnia 2008
Plan
1
Czym są i do czego służą Web Services?
2
Trzy podejścia
3
REST – REpresentational State Transfer
4
Prosty przykład
5
Bezpieczeństwo
6
Przykłady: Flickr (zły) oraz Google (dobry)
Piotr Domagalski
Podejścia do realizacji Web Services (2)
Czym są Web Services?
Definicja World Wide Web Consortium (W3C):
a software system designed to support interoperable Machine
to Machine interaction over a network
Najczęściej rozumiane jako wykorzystanie protokołu SOAP
(Simple Object Access Protocol) oraz WSDL (Web Services
Description Language)
Istnieje też co najmniej jedno odmienne podejście do
problemu...
Piotr Domagalski
Podejścia do realizacji Web Services (3)
Jakie problemy rozwiązujemy?
Enterprise Application Integration (EAI)
Integracja (starych) systemów w celu umożliwienia ich pełniejszego
wykorzystania jako całości w ramach organizacji
Cross-Organization Integration (B2B)
Udostępnienie publicznych interfejsów partnerom lub klientom
w celu zdalnego dostepu do systemów w organizacji
Różne wymagania, różne implikacje.
Piotr Domagalski
Podejścia do realizacji Web Services (4)
Trzy podejścia
1
Własny protokół
2
Podejście szkieletowe/pionowe (Framework approach)
3
Podejście poziome (Horizontal protocol approach)
Piotr Domagalski
Podejścia do realizacji Web Services (5)
Własny protokół
Istniejące rozwiązania są niewystarczające lub nie chcemy
czekać aż osiągną dojrzałość
Tworzymy własny protokół dla danego problemu, opierając się
na jednym z podstawowych rozwiązań (np. TCP/IP)
Łatwo wprowadzić błędy rozwiązując już raz rozwiązane
kwestie
Rozwiązanie drogie, wymaga sporych umiejętności –
praktycznie nieustające prace nad protokołem (np. nowe
mechanizmy bezpieczeństwa)
Rzadko spotykane obecnie
Piotr Domagalski
Podejścia do realizacji Web Services (6)
Podejście szkieletowe/pionowe
Narzędzie do tworzenia własnego protokołu aplikacyjnego
Pożądane cechy:
system typów
model adresowania
język opisu usługi
sposób wykorzystania protokołów niższego poziomu
(ang. bindings)
wbudowane mechanizmy bezpieczeństwa
Najpopularniejszy przykład: SOAP+WSDL
Zmniejsza ilość wymaganej pracy
Programista dostaje narzędzia wysokiego poziomu – używa
kreatora czy też dodaje krótkie adnotacje do metod
Implementacja (metody/funkcje) są bezpośrednio mapowane
na zewnętrzny interfejs
Piotr Domagalski
Podejścia do realizacji Web Services (7)
Podejście szkieletowe/pionowe – w czym problem?
Brak słabego powiązania (and. loosely coupled) interfejsu
i implementacji
Ukrywana jest spora warstwa niższego poziomu (XML
w SOAP-ie) – ta warstwa odpowiada jednak za rozszerzalność
i interoperacyjność interfejsu
Narzędzia zapewniają szybki start, ale standardowy efekt nie
nadaje się do profesjonalnych zastosowań – złudne poczucie
pewności
Wiara, że zastosowanie XML-a automatycznie rozwiązuje
problem interoperacyjności
Duża liczbę nowych protokołów – to nie ułatwia integracji
Piotr Domagalski
Podejścia do realizacji Web Services (8)
Podejście poziome
Podejście radykalne – nie twórzmy nowego protokołu dla
każdego nowego problemu
Weźmy jeden lub kilka protokołów ogólnego użytku, które
zostały dobrze sprawdzone w praktyce
Niech posiada takie cechy, jak:
definicję obiektu i operacji na nim: tworzenia, pobierania,
uaktualniania, usuwania
bezpieczeństwo
jednolitą przestrzeń adresową
wsparcie dla systemów pośredniech (ang. intermediaries)
wykazaną skalowalność
rozszerzalność
Piotr Domagalski
Podejścia do realizacji Web Services (9)
Podejście poziome (2)
Przykładem protokół HTTP:
szeroko używany – przetestowany
zasoby identyfikowane za pomocą URI
GET, PUT, POST, DELETE (ang. CRUD – Create Retrieve
Update Delete)
TRACE, OPTIONS, HEAD, CONNECT
niedoceniany – posiada wiele interesujących możliwości
Nie rozwiązuje problemu interoperacyjności, ale pozbywamy
się jednego źródła problemów
Uzgadniamy tylko model danych
W podejściu pionowym: szkielet (framework), protokół,
sposób adresowania, model danych!
Gotowa infrastruktura, np. HTTP cache może działać bez
dodatkowej wiedzy o domenie problemu
Piotr Domagalski
Podejścia do realizacji Web Services (10)
Podejście poziome (3)
Jak mógłby wyglądać „świat”?
HTTP jako protokół e-mail
Skrzynki identyfikowane przez URI
Każda wiadomość ma swoje unikalne ID (URI)
Każdy program znający protokół WebDAV (Windows Explorer,
Microsoft Office, ...) miałby dostep do poczty
Zamiast przesyłać duże wiadomości, przesyłalibyśmy referencje
(URI)
Dlaczego tak nie wygląda?
Przekonanie, że nie ma wystarczająco ogólnego protokołu
Wystarczyłoby zaufać (przykładowo) HTTP, którego można
rozszerzyć (przykład: WebDAV)
Piotr Domagalski
Podejścia do realizacji Web Services (11)
Często spotykane rozwiązanie
Koncepcja bazy danych ogólnego przeznaczenia
GetCustomer, DeleteCustomer, InsertCustomer,
UpdateCustomer
SELECT, DELETE, INSERT, UPDATE
Unix
> aby nadpisać plik
>> aby dodać do pliku
< aby odczytać plik
rm aby usunać plik
Operator | w powłoce
Ogólnie: wiele rzeczowników, do których stosujemy ograniczoną
liczbę czasowników
Piotr Domagalski
Podejścia do realizacji Web Services (12)
REST
Architektura sieci Web to REpresentational State Transfer
(REST) – definicja Roy’a Fieldinga
Cele:
Skalowalność komponentów – sieć Web rozrosła się
wykładniczo, a nadal zachowuje wydajność
Ogólność interfejsów – każdy klient może „rozmawiać”
z serwerem (SOAP?)
Niezależne wdrożenia komponentów
Komponenty pośrednie: wydajność, bezpieczeństwo,
enkapsulacja starych systemów
Spełnia założenia podejścia poziomego: HTTP, (X)HTML,
Javascript, Java, Flash, ...
Piotr Domagalski
Podejścia do realizacji Web Services (13)
REST – 4 zasady
Identyfikacja zasobów
Manipulacja zasobami poprzez ich reprezentacje
Samowystarczalne wiadomości
Stan aplikacji reprezentowany przez dokumenty (zasoby)
Piotr Domagalski
Podejścia do realizacji Web Services (14)
Dla porównania – problemy z SOAP
Pierwotne cele:
System RPC, który poradzi sobię z firewallami
Don Box – jedyną motywacją był brak w obecnym czasie
systemu typów dla XML
Nie protokół, a szkielet do tworzenia protokołów
Początkowo Simple Object Access Protocol (do wersji 1.1),
a później po prostu SOAP
Początkowo RPC typu one-way messaging – jaka przewaga na
CORBA, poza przepisaniem do XML-a?
Później... szkielet do przesyłania czegokolwiek1 – jak
integrować?
1
RPC/encoded, RPC/literal, Document/encoded, Document/literal
Piotr Domagalski
Podejścia do realizacji Web Services (15)
Problemów c.d.
„The Web is simply defined as the universe of global
network-accessible information” – Tim Berners-Lee
Systemy udostępniają obiekty w tym świecie
W klasycznym podejściu do Web Services (SOAP), Web to
tylko transport
Praktycznie brak wykorzystania URI
Jak wykorzystać standardy W3C (RDF, XPath, XQuery,
XSLT, XInclude, etc) skoro zasoby nie są identyfikowalne?
Jednolita przestrzeń nazw ułatwia integrację komponentów,
które początkowo nie miały być integrowane
„The utility of an operating system is more proportional to the
number of connections possible between its components than it is
to the number of those components.” – Hans Reiser
Piotr Domagalski
Podejścia do realizacji Web Services (16)
REST oraz HTTP – też nie ideał
Komunikacja głównie od klienta do serwera
Brak dobrego języka opisu – WSDL nie jest (jeszcze)
odpowiedni
Bezpieczeństwo?
Wymaga innego podejścia – zapomnij o RPC
Mniejsze wsparcie wśród narzędzi – coś się jednak dzieje, np.
JAX-RS: The Java API for RESTful Web Services
Piotr Domagalski
Podejścia do realizacji Web Services (17)
Stwórzmy więc prosty RESTful Web Service
Pytania:
1
2
Jakie wyróżniamy zasoby (URI)?
Jaki format danych?
HTTP Content Negotiation
3
Jakie metody HTTP dostępne pod danym URI?
4
Jakie kody w protokole HTTP wykorzystujemy?
Piotr Domagalski
Podejścia do realizacji Web Services (18)
Zasoby
Lista pracowników – http://company.com/employees
Każdy pracownik – http://company.com/employees/1234
Można też pójść dalej –
http://company.com/employees/1234/phone
Zaleta: dostęp do każdego zasobu, można linkować, zapisać w
zakładkach
Piotr Domagalski
Podejścia do realizacji Web Services (19)
Format danych (1)
Pracownik:
<employee xmlns=’http://company.com/ns/employee’>
<name>Full name goes here.</name>
<title>Person’s title goes here.</title>
<phone>Phone number goes here.</phone>
</employee>
Piotr Domagalski
Podejścia do realizacji Web Services (20)
Format danych (2)
Lista pracowników:
<employees xmlns=’http://company.com/ns/employees’>
<employeeRef href="URI of the first employee"/>
<employeeRef href="URI of employee #2"/>
<employeeRef href="URI of employee #N"/>
</employees>
Piotr Domagalski
Podejścia do realizacji Web Services (21)
Metody
/employees
GET – pobierz listę
POST – dodaj pracownika
/employees/1234
GET – pobierz reprezentację pracownika
PUT – uaktualnij dane pracownika
POST – dodaj dane pracownika
DELETE – usuń pracownika
Piotr Domagalski
Podejścia do realizacji Web Services (22)
Zwracane kody HTTP
Przykładowo:
200 – OK
201 – Created
400 – Bad Request
401 – Unauthorized
404 – Not Found
410 – Gone
Piotr Domagalski
Podejścia do realizacji Web Services (23)
Błędne rozumienie REST
Samo użycie HTTP nie wystarcza
Nadużycia POST
Poleganie na strukturze URI
Nazwy akcji w URI (w GET!)
Sesje
Własne identyfikatory obiektów
Piotr Domagalski
Podejścia do realizacji Web Services (24)
SOAP 1.2 – ukłon w stronę REST?
POST oraz dodatkowo GET
Specyfikacja wspomina (zalecenie) o użyciu SOAP-a w World
Wide Web2
Identyfikacja zasobów w URI
Za pomocą GET można pobrać reprezentację danego zasobu
Ale kto o tym wie? Jakie narzędzie to wspiera?
2
SOAP Version 1.2 Part 2: Adjuncts, p. 4.1
Piotr Domagalski
Podejścia do realizacji Web Services (25)
Bezpieczeństwo a REST
SOAP miał za zadanie „omijać” firewalle
Programista nie chce zajmować się kwestiami bezpieczeństwa –
usługa ma działać
Upublicznione zostają interfejsy RPC, na które administrator
normalnie by nie pozwolił!
Jak monitorować taki ruch?
SOAPAction
HTTP identyfikuje zasoby oraz operacje na nich – te ze
skutkami ubocznymi oraz bez
DELETE /employees/1234 HTTP/1.1
host: www.company.com
Piotr Domagalski
Podejścia do realizacji Web Services (26)
Przykład – Flickr API
Obsługiwane zapytania w XML-RPC, SOAP oraz REST
REST – nakładka na system RPC pod spodem?
„REST is the simplest request format to use – it’s a simple
HTTP GET or POST action”
„The REST Endpoint URL is
http://api.flickr.com/services/rest/”
Nazwa metody zakodowana w URL
Brak wykorzystania kodów HTTP
To nie jest architektura REST!
Piotr Domagalski
Podejścia do realizacji Web Services (27)
Przykład – Google
W okolicach 2000 roku istniało nieudokumentowane API – po
podmianie /search na /xml dostawaliśmy wyniki
wyszukiwania w XML-u
Google przeszło na SOAP-a i w Internecie zawrzało:
Marketingowy szum wokół SOAP dotarł w końcu do Google’a
„To jak krok do przodu i dwa kroki do tyłu”
„Obfuscating layer over a simple XML/HTTP/URI service”
Amazon3 , eBay – pozostało wtedy przy XML/HTTP/URI
3
W 2004 REST (85%) oraz SOAP
Piotr Domagalski
Podejścia do realizacji Web Services (28)
Przykład – Google obecne APIa
a
http://code.google.com/apis/
1
Oparte na Google Data API
Apps APIs
Base Data API
Blogger Data API
Calendar Data API
Code Search Data API
Contacts Data API
Documents List Data API
Notebook Data API
Web Albums Data API
Spreadsheets Data API
YouTube Data API
2
Inne
Operte na SOAP: AdSense (for Audio) API, AdWords API
AJAX APIs: Feed API, Language API, Search API, Book
Search API, Maps API
Piotr Domagalski
Podejścia do realizacji Web Services (29)
Przykład – Google Data API
Większość protokołów opiera się na Google Data API –
wykorzystanie HTTP w duchu REST!
Google Data API – „a simple standard protocol for reading
and writting data on the web”:
Protokół oparty na HTTP: GET, POST, PUT, DELETE oraz
kody HTTP
Oparte na RSS, Atom i Atom Publishing Protocol (draft)
Rozszerzenia formatu Atom
Optimistic concurrency
Piotr Domagalski
Podejścia do realizacji Web Services (30)
Bibliografia
http://tomayko.com/writings/rest-to-my-wife – How
I Explained REST to My Wife
http://www.xml.com/pub/a/2002/02/06/rest.html –
Second Generation Web Services
http://www.prescod.net/ – strona Paula Prescoda
http://rest.blueoxen.net/ – REST Wiki
http://www.xent.com/pipermail/fork/2001-August/
002923.html – The Dining Philosophers in REST
http://webservices.xml.com/pub/a/ws/2002/04/24/
google.html – Google’s Gaffe
http://code.google.com/apis/gdata/overview.html –
Google Data API
Piotr Domagalski
Podejścia do realizacji Web Services (31)
A na koniec...
Czas na dyskusję!
Piotr Domagalski
Podejścia do realizacji Web Services (32)