Web services w PHP Inżynieria e-systemów - technologia Java Miłosz Dybizbański Małgorzata Gocał Kinga Knapik

Prezentacja na temat: "Web services w PHP Inżynieria e-systemów - technologia Java Miłosz Dybizbański Małgorzata Gocał Kinga Knapik"— Zapis prezentacji:

1 Web services w PHP Inżynieria e-systemów - technologia Java Miłosz Dybizbański 171091 Małgorzata Gocał 171082 Kinga Knapik 171046

2 Web services Web services (WS) jest to ogólna nazwa dla technologii dostępu do zdalnych procedur wykorzystująca do komunikacji standardowe techniki przekazywania danych – HTTP – oraz XML jako źródło danych. WS jest interfejsem umożliwiającym komunikację między aplikacjami, niezależnie od rodzaju platformy, na której pracują, oraz języka użytego do ich tworzenia. Żądania są, w postaci specjalnie sformatowanego XML’a, wysyłane przez POST protokołem HTTP, a następnie wynik działania zwracany jest do użytkownika, także w postaci XML’a. 2

3 Warstwy web services WS dzielimy na trzy warstwy: Packaging – jest to warstwa wymiany danych Description – jest to warstwa opisu API web servisu Discovery – jest to warstwa opisu natury web servisu 3

4 Warstwy WS - Packaging Wymiana danych odbywa się poprzez TCP/IP na porcie 80. rozwiązanie ma tę zaletę, że przepuszcza je firewall bez potrzeby dodatkowej konfiguracji. Warstwa packaging korzysta z ustalonych standardów: SOAP XML-RPC OAuth SCA 4

5 SOAP Protokół wywoływania zdalnego dostępu do obiektów. Jest standardem organizacji W3C. Składa się z trzech elementów: opakowania definiującego framework, opisującego wiadomość (oraz to jak ją przetwarzać), zestawu zasad kodowania opisujących instancje zdefiniowanych w aplikacji typów danych konwencji dla prezentacji zdalnych wywołań procedur i odpowiedzi 5

6 SOAP – blok wiadomości Głównym elementem jest blok wiadomości – mesage. Zawiera on następujące elementy: Element opakowania – envelope – identyfikuje on SOAP’a. zawiera on także następujące przestrzenie nazw dla envelope i kodowania. Opcjonalnie nagłówek – header. Element ciała SOAP – body – znajdują się w nim wywołania jak i odpowiedzi serwera. Opcjonalny element błędów – fault – dostarczający informacje o błędach, które powstały podczas przetwarzania wiadomości. 6

7 SOAP – przykład szkieletu 7

8 SOAP – envelope Envelope musi zawierać przestrzenie nazw podane w przykładzie poniżej. Header zawiera opis wiadomości SOAP. Jest on opcjonalny, lecz gdy już się pojawi musi on być pierwszym podelementem w elemencie envelope. W przykładzie podany jest atrybut mustUnderstand. Ustawienie go na 1/true oznacza, że parser odpowiedzialny za przetworzenie headera musi rozpoznać ten element, w przeciwnym razie ma zwrócić błąd. 8

9 SOAP – body W elemencie body podawane są rozkazy dla serwisu, a także zwracane są jego odpowiedzi. W przykładzie widzimy, że wywołujemy metodę GetLoginName z parametrem 42. 9

10 SOAP – body Odpowiedź serwera może być następująca: W odpowiedzi dostaliśmy wartość, która jest nazwą loginu dla podanego ID. 10

11 SOAP – fault Element fault zawiera informacje o błędach. Jest on zawsze elementem body i może pojawić się tylko raz w wiadomości. Zawiera następujące elementy: - kod błędu. Dostępne kody błędów to: –VersionMismatch - błąd określający niepoprawną przestrzeń nazw w elemencie envelope –MustUnderstand - jeżeli ustawiliśmy w headerze wartość mustUnderstand na 1, a serwer nie rozpoznał nagłówków, zwracany jest właśnie ten błąd –Client - wiadomość SOAP wysłana od klienta była niepoprawna –Server - wystąpił błąd na serwerze, dlatego wiadomość nie mogła zostać obsłużona - tekst błędu - informacja o tym kto/co spowodowało błąd - szczegóły błędu 11

12 SOAP – implementacje PHP-SOAP – to rozwijająca się implementacja posiadająca jednak już sporo możliwości i łatwe API. Dokumentacja pozostawia wiele do życzenia, ale przykłady zastosowania tej implementacji pozwalają łatwo zrozumieć sposób budowania Web Services w oparciu o tą implementację. nuSOAP - jest to dobrze udokumentowana implementacja, która cały czas się rozwija co dobrze wróży jej na przyszłość. Istnieje także lista mailowa, na której można zadawać pytania dotyczące nuSOAP’a. 12

13 XML-RCP Został zaprojektowany jako łatwy w implementacji i bardzo prosty system pakowania danych dla zdalnych procedur. Mimo swej prostoty oferuje kompleksowe wsparcie dla przekazywania złożonych struktur danych. Typy danych jakimi dysponuje XML-RPC to: 32-bitowy integer - znaczniki: lub Boolean - znacznik: Znaki z tablicy ASCII - znacznik: "Podwójnie precyzyjne" liczby zmienno-przecinkowe - znacznik: Data i czas w formacie ISO 8601 (przykład: 19980717T14:08:55) - znacznik: Base64-encoded binary - znacznik: Struktury danych - znacznik: Tablice - znacznik: 13

14 XML-RCP – przykład zapytania Przykład zapytania, jakie wysyłane jest do serwera WS w „czystej” postaci Z tego przykładu widać, że chcemy wywołać metodę getStateName obiektu examples z parametrami typu integer o wartości 41. 14

15 XML-RCP – przykład zapytania Przykład odpowiedzi, jaka wysyłana jest od serwera WS 15

16 XML-RCP - implementacje IXR – jest to bardzo ułatwiająca pracę implementacja. Została zaprojektowana, aby osoby znające powierzchownie WS mogły bez problemu poradzić sobie z napisaniem serwera jak i klienta WS. Posiada udogodnienia takie jak łatwa konwersja typów PHP do postaci XML-RPC czy też możliwość tworzenia własnych rozszerzeń. phpxmlrpc – zostało napisane przez samych twórców XML-RPC - Useful Inc. - co od razu sugeruje pełne wsparcie standardu. Zaletami implementacji są jej duże możliwości. Dostarcza wiele elementów niezbędnych w tworzeniu WS jednak dla mniej wtajemniczonych użytkowników może nastręczać problemów na przykład w podawaniu typów zmiennych czy korzystania z dostępnych obiektów. phpRPC – dysponująca możliwościami wykraczającymi poza zwykłe wysyłanie i odbieranie rządań i odpowiedzi. XML-RPC Client/Server (K. Devense) – zestaw funkcji umożliwiające w łatwy sposób stworzenie klienta i serwera XML-RPC. eZ xmlrpc – klasa do obsługi XML-RPC dostępna w eZ Publish. 16

17 OAuth OAuth to otwarty protokół pozwalający na bezpieczną autoryzację za pomocą API dla aplikacji desktopowych, mobilnych i aplikacji internetowych. OAuth pozwala użytkownikowi dać dostęp do jego informacji, opcji na stronie A (dostawcy OAuth, np. Twitter czy Facebook) innej stronie B (konsumentowi) bez podawania pełnych danych uwierzytelniających (np. bez podawania loginu i hasła). Standard ten obecnie jest implementowany na coraz większej liczbie stron, jako że pozwala im wystawiać bezpieczniejsze API, jak i dające pewność użytkownikami co zewnętrzna strona z nimi zrobi. 17

18 SCA 18

19 Warstwy WS - Description Jest to warstwa opisu API web serwisu 19

20 Warstwy WS - Discovery Jest to warstwa opisu natury web serwisu 20