REST

• Representational State Transfer - style architektoniczny
  • metaarchitektura, metodologia
• założenia
  • architektura klient-serwer
  • bezstanowość (*cache*)
  • buforowanie podręczne
  • jednolity interfejs dostępu
• Jednolity interfejs
  • jednolita identyfikacja / adresacja zasobów URL jest pewną referencją, pod którym coś się ukrywa, nie musi to być plik, może być usługa
  • manipulacja zasobami poprzez ich reprezentacje
  • samoopisujące się wiadomości (bezstanowość)
  • powiązania między zasobami (wyrażone w reprezentacjach)
• skalowalność interakcji komponentów
• ogólność interfejsów
• niezależność wdrażania komponentów
  • looce coupling
  • możliwość aktualizacji/rozszerzania protokołu
• Możliwość wprowadzania usług pośredniczących
  • redukcja opóźnień
  • zwiększenie bezpieczeństwa
  • opakowywanie zastanych systemów (gateways)

• Założenia ROA - Resource Oriented Architecture
  • Wykorzystanie URI do identyfikacji zasobów
  • jakieś polecenia http

• Prostota
• Mniejszy narzut obliczeniowy
  • brak dodatkowego opakowania zleceń (SOAP)
  • brak konieczności przetwarzania dokumentów XML
• wykorzystanie znanej i przetestowanej infrastruktury web
• możliwość stosowania serwerów pośredniczących
• Semantyka operacji
• charakter zlecanego przetwarzania (odczyt, modyfikacja)

(inne rzeczy których nie zdążyłem przepisać)

• SOAP traktuje Web jako mechanizm transportowy do przesyłania wiadomości interpretowanych przez aplikacje spoza Web
  • tunelowanie wiadomości przez web
  • nie po to tworzony był web
  • nie za bardzo nadaje się do tego celu
• SOAP korzysta tylko z rozmytej, semantycznej metody
• POST protokołu HTTP pomijając najsilniejsze strony web
• web jest już integrującą szyną komunikacyjną (ESB) wyposażoną w coś czego nie przepisałem
• fundamentem dla web są intentyfikatory URI
• web services pozostawiają zarządzanie nazwami aplikacjom
• soap stosuje uri tylko do wskazywania punktu dostepu do usługi, która zarządza wszystkimi wewnętrznymi zasobami, np:

bank = new SOAPProxy("http://bank.pl/ws");
bank.addMoneyToAccount("382198309183", 540.5);

• brak bezpośredniego dostępu do konta (tylko bank)
• nowa przestrzeń nazw dla numeracji kont

• wiele protokołów/technologii zakłada wykorzystanie uri do adresacji zasobów

(nie zdążyłem przepisać, slajd trwał ułamek sekundy)

• Zdalne wywoływanie procedur
  • Java RMI, CORBA, Web Services
• Architektura zorientowana na zasoby
  • usługi sieciowe REST
• coś jeszcze o czym nic nie powiedział

• Podstawowe pojęcia używane przy opisie usługi
  • operacje wykonywane/oferowane przez usługę
  • zasoby udostępnione przez usługę
• wybór determinuje sposób modelowania i projektowania usługi
• usługa może udostępniać oba interfejsy
• nie ma możliwości automatyzacji tranlacji (…)

POST /we HTTTP/1.1
Host: books.example.com
ContentType: application/soap+xml <- co dostajemy
ContentLength: 165 <- ile dostajemy
<?xml ...

• Rest

GET /books/12345 HTTP/1.1
Host: books.example.com

• istotne różnica
  • wykorzystanie metody get zamiast post
  • jawna reprezentacja zasobu /books/12345
  • brak dodatkowej koperty

GET /service?method=lookupBook&id=12345 HTTP/1.1
Host: books.example.com

• Uwagi:
  • ograniczanie się do protokołu HTTP
  • metody modyfikujące wywływane metoda GET

• WS-*: WSDL + XML Schema
  • silne typowanie
  • możliwość automatycznego generowania kodu
• REST:
  • WADL - Web application description language
    • modelowanie zasobów i relacji pomiędzy nimi
    • uri + metoda + arg, we ! wynik
  • WSCDL 2.0
  • odkrywanie usługi (calling | navigation)

• WS-*: UDDI
  • standard okrzepły, ale
  • mała liczba publicznych, otwartych repozytoriów usług
• REST: po prostu Web
  • wyszukiwarki internetowe
  • microformats

• obszary zastosowań usług sieciowych (architektury SOA)
• zastosowania przemysłowe (ENTERPRISE!)
  • preferencje WebServices
  • dużo innych rzeczy

koniec slajdów