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

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 – m.in. 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. 2

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

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 REST OAuth SCA 4

SOAP Protokół wywoływania zdalnego dostępu do obiektów. Jest standardem organizacji W3C. Składa się z trzech elementów: koperty (ang. envelope), opisującej zawartość komunikatów oraz sposoby ich przetwarzania zestawu zasad kodowania opisujących instancje zdefiniowanych w aplikacji typów danych konwencji dla prezentacji zdalnych wywołań procedur i odpowiedzi 5

SOAP – blok wiadomości Głównym elementem jest blok wiadomości – message. Zawiera on następujące elementy: Element opakowania – envelope – identyfikuje on SOAP’a. Zawiera 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

SOAP – przykład szkieletu 7

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

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

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

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

SOAP – implementacje w PHP PHP-SOAP – to rozwijająca się implementacja posiadająca jednak już sporo możliwości i przyjazne API. Przykład zastosowania tej implementacji: [PRZYKŁAD] ;) nuSOAP – udokumentowana, stale rozwijana implementacja [link do dokumentacji dobrej]. Istnieje także lista mailowa, na której można zadawać pytania dotyczące nuSOAP’a [Co to za lista? Gdzie ona jest? www ;) adres, cokolwiek]. 12

WSDL Web Services Description Language (WSDL) -

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: T14:08:55) - znacznik: Base64-encoded binary - znacznik: Struktury danych - znacznik: Tablice - znacznik: 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

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

XML-RCP – implementacje w PHP 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. Zaletami implementacji są jej duże możliwości. Dostarcza wiele elementów niezbędnych w tworzeniu WS, jednak dla mniej doświadczonych użytkowników może nastręczać problemów na przykład w podawaniu typów zmiennych czy korzystania z dostępnych obiektów. XML-RPC Client/Server (K. Devense) – zestaw funkcji umożliwiające w łatwy sposób stworzenie klienta i serwera XML-RPC. Inne: –eZ xmlrpc –php-RPC 17

XML-RCP – przykład implementacji Jest to przykład klasy w oparciu o implementację XML-RPC Client/Server, korzysta ona z bibliotek XML_RCP2 oraz Cashe_Lite z pakietu PEAR.

XML-RCP – przykład implementacji Przykład komunikacji z Flickrem: Wynik przykładu:

REST Wzorzec architektury oprogramowania opierający się na bezstanowej wymianie informacji w środowisku rozproszonym. Jako nośnik informacji wykorzystuje m.in. formaty XML i JSON. Mówiąc prościej, usługa REST to odpowiednio zapisany ciąg znaków w formie adresu URI [URL??], który następnie przysyłamy do zewnętrznej aplikacji metodą GET, co skutkuje zwrotem żądanych danych. Aby jeszcze bardziej ułatwić korzystanie z protokołu REST można posłużyć się repozytorium PEAR (PHP Extension and Application Repository). W przykładzie przedstawiona jest abstrakcyjna klasa, która wykona połączenie GET i pobierze dane z serwera, a następnie dokona deserializacji do tablicy PHP. 20

REST – przykład podstawowej klasy 21

REST – przykład podstawowej klasy Powyżej znajduje się krótka klasa dziedzicząca z klasy REST_Parser. Pokazuje ona przykładowe użycie klasy abstrakcyjnej z poprzedniego slajdu. 22

REST – test oraz wynik działania przykładu W wyniku użycia powyższego kodu na stronie ukaże się: 23

OAuth otwarty protokół pozwalający na bezpieczną autoryzację za pomocą API dla aplikacji desktopowych, mobilnych i internetowych, pozwala na dostęp do informacji użytkownika ze strony A (dostawcy OAuth, np. Twitter czy Facebook) innej stronie B (konsumentowi), nie wymaga podawania pełnych danych uwierzytelniających, standard ten obecnie jest implementowany na coraz większej liczbie stron, jako że pozwala im wystawiać bezpieczniejsze API. 24

OAuth – przykład użycia Należy zarejestrować klienta na Podajemy nazwę naszej aplikacji, jej typ oraz adres URL strony, na którą zostanie przekierowany użytkownik po autoryzacji. Twitter generuje klucz Consumer key oraz Consumer secret, a także podaje podstawowe adresy URL API.

OAuth – przykład użycia Korzystając z binarnego rozszerzenia Pecl kod do uwierzytelniania użytkownika wygląda tak:

OAuth – przykład użycia Po udanym zalogowaniu użytkownik jest przekierowany na adres URL podany jako callback, jego obsługa może wyglądać następująco:

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

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

PEAR (PHP Extension and Application Repository) PEAR jest frameworkiem i systemem dystrybucyjnym rozszerzeń języka PHP. rozszerza podstawowe funkcje PHP, przydatny w zaawansowanych systemach używających tego języka, przydatny w tworzeniu web servisów.

Pecl Repozytorium rozszerzeń języka PHP. Nazwa jest skrótem od "PHP Extension Community Library". Zawiera darmowe moduły oparte na licencji open source tworzone przez programistów z całego świata. Począwszy od wydania PHP 5 do PECL przeniesionych zostało wiele wcześniejszych modułów oficjalnych, najczęściej tych niestabilnych lub rzadko używanych. Jest siostrzanym systemem PEARa.