Integracja aplikacji Wykład 4 Piotr Czapiewski Wydział Informatyki ZUT Integracja aplikacji Wykład 4
RESTful Web Services
REST – styl architektoniczny REpresentational State Transfer Praca doktorska Roya Fieldinga „Architectural Styles and the Design of Network-based Software Architectures” („The REST bible”) http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm Określony poprzez zbiór ograniczeń (constraints), które należy spełnić Odpowiada zasadom leżącym u podstaw HTTP Web, HTTP, URI – jedna z możliwych realizacji
RESTful HTTP „The Web Used Correctly” Architektura systemu lub aplikacji Ściśle związana z Siecią Wykorzystująca HTTP, URI i inne standardy Webowe we właściwy sposób Inne określenia: Web-Oriented Architecture (WOA) Resource-Oriented Architecture (ROA)
REST – podstawowe zasady Give Every „Thing” an ID Link Things To Each Other Use Standard Methods Allow for Multiple „Representations” Communicate Statelessly
1. Give Every „Thing” an ID Identyfikuj wszystko, co zasługuje na identyfikację Wysokopoziomowe zasoby, abstrakcje, fizyczne lub wirtualne obiekty, kolekcje obiektów, wyniki obliczeń, procesy Zunifikowane, globalne ID = URI http://example.com/customers/1234 http://example.com/orders/2007/10/776654 http://example.com/products/4554 http://example.com/processes/salary-increase-234 Sprawdzona, zrozumiała, globalna przestrzeń nazw Możliwość przesłania linka do zasobu
2. Link Things To Each Other „Hypermedia as the engine of application state” „Hyperlinking is what makes the Web the Web” Wykorzystuj hiperlinki do opisu relacji pomiędzy obiektami <order self='http://example.com/customers/1234' > <amount>23</amount> <product ref='http://example.com/products/4554' /> <customer ref='http://example.com/customers/1234' /> </order>
3. Use Standard Methods Każdy zasób identyfikowany przez URI wspiera ten sam interfejs: Operacje zdefiniowane w specyfikacji HTTP Metody GET, POST, PUT, DELETE Obiektowa analogia zasobu w RESTful HTTP: class Resource { Resource(URI u); Response get(); Response post(Request r); Response put(Request r); Response delete(); }
3. Use Standard Methods Znaczenie metod HTTP GET – zwróć reprezentację zasobu POST – utwórz nowy zasób, aktualizuj lub dołącz zasób podrzędny PUT – aktualizuj lub utwórz zasób DELETE – usuń zasób Bezpieczeństwo i idempotencja: GET, PUT, DELETE HTTP CRUD POST Create, Update GET Read PUT Update, Create DELETE Delete
3. Use Standard Methods
3. Use Standard Methods
3. Use Standard Methods
3. Use Standard Methods Każdy komponent rozumiejący HTTP może wchodzić w interakcję z naszą aplikacją Przeglądarka WWW curl, wget Proxy, cache, serwer HTTP Google
4. Allow for Multiple Representations Obsługa wyniku operacji Skąd klient ma wiedzieć, jakie dane otrzyma, np. w wyniku żądania GET? Separacja koncepcji wywołania operacji i obsługi wyniku Klient obsługuje konkretny format i o taki format prosi HTTP content negotiation
4. Allow for Multiple Representations Dobra praktyka: Udostępnienie XML i HTML Umożliwienie dostępu nie tylko konkretnej aplikacji, lecz także standardowej przeglądarce WWW Informacja dostępna dla każdego, kto potrafi korzystać z WWW Web UI = Web API Dostęp do aplikacji przez człowieka i przez maszynę
5. Communicate Statelessly Komunikacja bezstanowa Stan aplikacji zapisany jako stan zasobu lub Stan aplikacji zapisany po stronie klienta Serwer nie powinien przechowywać informacji o stanie komunikacji z klientem ponad to, co dotyczy bieżącego, pojedynczego żądania
REST a komponenty HTTP Pełne wykorzystanie operacji HTPP Negocjacja formatu zawartości GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE Przekierowanie Caching Kompresja Ustandaryzowane kody odpowiedzi 403 – brak dostępu 404 – zasób nie odnaleziony 500 – błąd aplikacji
REST vs. SOAP SOAP Web Services RESTful Web Services „Web” tylko w nazwie – słaba integracja z HTTP, ignorowanie cech Internetu „Protocol independence is a bug, not a feature” Osobny interfejs dla każdej usługi, protokół zależny od aplikacji Niewielkie różnice w stosunku do starszych rozwiązań (CORBA, DCOM, RMI) – „CORBA with angle brackets” RESTful Web Services Jeden, wspólny dla wszystkich interfejs Mapowanie podstawowych operacji na semantykę zasobów Standardowy protokół aplikacji (HTTP) Słabsze wsparcie ze strony narzędzi
REST vs. SOAP SOAP Web Services RESTful Web Services Przywiązanie do XML Duże narzuty w komunikacji RESTful Web Services Obsługa XML i innych formatów Lekkie komunikaty <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:body pb="http://www.acme.com/phonebook"> <pb:GetUserDetails> <pb:UserID>12345</pb:UserID> </pb:GetUserDetails> </soap:Body> </soap:Envelope> http://www.acme.com/phonebook/UserDetails/12345
REST vs. SOAP – przykład żądania <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:body pb="http://www.acme.com/phonebook"> <pb:GetUserDetails> <pb:UserID>12345</pb:UserID> </pb:GetUserDetails> </soap:Body> </soap:Envelope> http://www.acme.com/phonebook/UserDetails/12345
REST vs. SOAP – przykład odpowiedzi <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:body pb="http://www.acme.com/phonebook"> <pb:GetUserDetailsResponse> <pb:User> <pb:UserID>12345</pb:UserId> <pb:Name>Jan Kowalski</pb:Name> <pb:Phone>911234567</pb:Name> <pb:Email>jkowal@poczta.pl</pb:Email> </pb:User> </pb:GetUserDetailsResponse> </soap:Body> </soap:Envelope> <?xml version="1.0"?> <User> <UserID>12345</UserId> <Name>Jan Kowalski</Name> <Phone>911234567</Name> <Email>jkowal@poczta.pl</Email> </User>
REST vs. SOAP SOAP Web Services RESTful Web Services 1 URL dla każdej usługi 1 metoda POST, wiele operacji RESTful Web Services Osobny URL dla każdego zasobu Kilka wspieranych metod (GET, PUT,POST, DELETE) Cacheable, addressable, linkable…
REST i SOAP a style integracji Remote Procedure Call SOAP Messaging
REST vs. SOAP Co z bezpieczeństwem, szyfrowaniem, obsługą sesji, QoS, itd.? RESTful Web Services Brak standardowych mechanizmów Możliwość budowy własnych rozwiązań SOAP Web Services W podstawowych standardach – brak Rodzina protokołów WS-*
REST vs. SOAP REST Właściwy dla prostych, podstawowych scenariuszy integracji SOAP Właściwy w bardziej zaawansowanych scenariuszach integracji Uwzględnia wymagania QoS występujące w systemach korporacyjnych
RESTful Web Services – przykłady Dostępne usługi Google Base, GData, Calendar, Documents, Blogger, Notebook, Picasa Amazon Simple Storage Service, Queue Service, Flexible Payment, Search Narzędzia Sun Jersey, JSR 311 IBM Abdera, Project Zero Microsoft WCF
RESTful Web Service – przykłady Online REST Web Service Demo http://www.thomas-bayer.com/rest-demo.htm Baza danych SQL udostępniona jako usługa REST Pobieranie, edycja, dodawanie, usuwanie wierszy/obiektów http://www.thomas-bayer.com/sqlrest/ http://www.thomas-bayer.com/sqlrest/CUSTOMER/18/ http://www.thomas-bayer.com/sqlrest/INVOICE/
RESTGate – webowy klient usług REST http://www.thomas-bayer.com/restgate/
Implementacja REST Java i biblioteka JAX-RS
REST i Java – JAX-RS JAX-RS: Java API for RESTful Web Services Część standardu Java EE 6 Standardowe API upraszczające tworzenie usług REST Oparte na adnotacjach Implementacje Jersey – implementacja referencyjna (Sun/Oracle) Apache CXF RESTEasy (JBoss)
Adnotacje JAX-RS Mapowanie klas/metod do zasobów webowych @Path @GET, @PUT, @POST, @DELETE Mapowanie parametrów żądania do parametrów metody @PathParam, @QueryParam, @HeaderParam, @CookieParam, @FormParam Określenie typów MIME dla reprezentacji zasobów @Produces @Consumes
Serwer usługi REST w JAX-RS package pc.rest; import javax.ws.rs.GET; import javax.ws.rs.Path; @Path("hello") public class HelloRest { @GET public String hello() { return "Witamy w JAX-RS"; } http://localhost:8080/RestTest01/resources/hello
Serwer usługi REST w JAX-RS Obsługa metod HTTP: GET POST PUT DELETE @Path("user") public class UsersService { @GET public String getUser() { // ... } @POST public String addUser() { @PUT public String updateUser() { @DELETE public String deleteUser() {
Serwer usługi REST w JAX-RS Negocjacja zawartości Tekst, XML, JSON Adnotacja @Produces Nagłówek HTTP accept @GET @Produces("text/plain") public String helloText() { return "Witamy w JAX-RS"; } @Produces("text/html") public String helloHtml() { return "<h1>Witamy w JAX-RS</h1>"; @Produces("application/xml") public String helloXml() { return "<komunikat>" + "<nadawca>Admin</nadawca>" + "<tresc>Witamy w JAX-RS</tresc>" + "</komunikat>";
Serwer usługi REST w JAX-RS Parametry żądania @Path("hello/{imie}") public class HelloRest { @GET @Produces("text/plain") public String helloText(@PathParam("imie") String imie) { return "Witaj w JAX-RS, " + imie; } http://localhost:8080/RestTest01/resources/hello/Piotr
Klient Rest – Java
Klient Rest – Java
Klient Rest – PHP Biblioteka Pest – https://github.com/educoder/pest
Literatura L. Richardson, S. Ruby: RESTful Web Services http://www.amazon.com/RESTful-Web-Services-Leonard-Richardson/dp/0596529260 A Brief Introduction to REST http://www.infoq.com/articles/rest-introduction Addressing Doubts about REST http://www.infoq.com/articles/tilkov-rest-doubts REST Anti-Patterns http://www.infoq.com/articles/rest-anti-patterns Tutorial: Jersey + Tomcat http://www.suryasuravarapu.com/2009/02/rest-jersey-configuration-on-tomcat.html http://www.suryasuravarapu.com/2009/03/rest-crud-with-jax-rs-jersey.html