Podejścia do realizacji Web Services

Transkrypt

1 Podejścia do realizacji Web Services czyli: Giving SOAP a REST Piotr Domagalski szalik@szalik.net 16 kwietnia 2008

2 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)

3 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)

4 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)

5 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)

6 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)

7 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)

8 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)

9 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)

10 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)

11 Podejście poziome (3) Jak mógłby wyglądać świat? HTTP jako protokół 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)

12 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)

13 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)

14 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)

15 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 czegokolwiek 1 jak integrować? 1 RPC/encoded, RPC/literal, Document/encoded, Document/literal Piotr Domagalski Podejścia do realizacji Web Services (15)

16 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)

17 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)

18 Stwórzmy więc prosty RESTful Web Service Pytania: 1 Jakie wyróżniamy zasoby (URI)? 2 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)

19 Zasoby Lista pracowników Każdy pracownik Można też pójść dalej Zaleta: dostęp do każdego zasobu, można linkować, zapisać w zakładkach Piotr Domagalski Podejścia do realizacji Web Services (19)

20 Format danych (1) Pracownik: <employee xmlns= > <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)

21 Format danych (2) Lista pracowników: <employees xmlns= > <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)

22 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)

23 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)

24 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)

25 SOAP 1.2 ukłon w stronę REST? POST oraz dodatkowo GET Specyfikacja wspomina (zalecenie) o użyciu SOAP-a w World Wide Web 2 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)

26 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: Piotr Domagalski Podejścia do realizacji Web Services (26)

27 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 Nazwa metody zakodowana w URL Brak wykorzystania kodów HTTP To nie jest architektura REST! Piotr Domagalski Podejścia do realizacji Web Services (27)

28 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 Amazon 3, ebay pozostało wtedy przy XML/HTTP/URI 3 W 2004 REST (85%) oraz SOAP Piotr Domagalski Podejścia do realizacji Web Services (28)

29 Przykład Google obecne API a a 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)

30 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)

31 Bibliografia How I Explained REST to My Wife Second Generation Web Services strona Paula Prescoda REST Wiki html The Dining Philosophers in REST google.html Google s Gaffe Google Data API Piotr Domagalski Podejścia do realizacji Web Services (31)

32 A na koniec... Czas na dyskusję! Piotr Domagalski Podejścia do realizacji Web Services (32)