Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00353 005982 13100566 na godz. na dobę w sumie
Nowoczesne API. Ewoluujące aplikacje sieciowe w technologii ASP.NET - książka
Nowoczesne API. Ewoluujące aplikacje sieciowe w technologii ASP.NET - książka
Autor: , , , , Liczba stron: 488
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-2391-9 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> webmasterstwo >> asp
Porównaj ceny (książka, ebook (-25%), audiobook).
Większość z najpopularniejszych dużych witryn internetowych zbudowano z użyciem technologii Web API. Może ona działać na podstawie protokołu HTTP — umożliwia wówczas łatwą pracę nad nowymi funkcjonalnościami aplikacji, kwestiami bezpieczeństwa, skalowalnością rozwiązań, obsługą nowych urządzeń lub aplikacji klienckich. W takim modelu aplikacji kluczowymi komponentami są typy danych i hipermedia. Wielu twórców API nie wykorzystuje jednak możliwości protokołu HTTP i wdraża API silnie powiązane z aplikacją klienta, co w zasadzie zamyka drogę do bezproblemowego ewoluowania systemu. Na dłuższą metę tego rodzaju rozwiązania są sprzeczne z podstawami internetu.

Niniejsza książka to wartościowy podręcznik dla projektantów, którzy chcą tworzyć API adaptujące się do zachodzących zmian. Autorzy zaprezentowali tu wszystkie narzędzia niezbędne do tworzenia ewoluujących systemów, a także przedstawili informacje dotyczące sieci i programowania Web API. Dokładnie omówili proces tworzenia nowego API za pomocą platformy ASP.NET Web API, z uwzględnieniem takich zagadnień, jak implementacja hipermediów z użyciem ASP.NET Web API oraz negocjowanie treści. Ten bardzo praktyczny podręcznik, pisany przez inżynierów oprogramowania, stanowi inspirację do projektowania najlepszych rozwiązań dla ewoluujących aplikacji internetowych.

W tej książce znajdziesz:

Odkryj możliwości HTTP na nowo!


Glenn Block — jeden z twórców ASP.NET, odpowiedzialny za przygotowanie jednej z poprzednich wersji ASP.NET Web API.
Pablo Cibraro — od czternastu lat projektuje i implementuje ogromne systemy rozproszone w centrach Microsoft Technologies.
Pedro Felix — naukowiec i inżynier oprogramowania, specjalizuje się w problematyce infrastruktury środowiska uruchomieniowego, w zarządzaniu tożsamością i w kwestiach związanych z kontrolą dostępu do danych.
Howard Dierking — menedżer programu w zespole WCF Web API w firmie Microsoft, obecnie kieruje pracami nad menedżerem pakietów NuGet i pracuje nad projektem Katana.
Darrel Miller — współzałożyciel Tavis Software, specjalizuje się w stosowaniu stylu architekturalnego REST w aplikacjach biznesowych.
Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Designing Evolvable Web APIs with ASP.NET Tłumaczenie: Robert Górczyński ISBN: 978-83-283-2391-9 © 2016 Helion S.A Authorized Polish translation of the English edition of Designing Evolvable Web APIs with ASP.NET 9781449337711 © 2014 Glenn Block, Pablo Cibraro, Pedro Felix, Howard Dierking, and Darrel Miller This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Pliki z przykładami omawianymi w książce można znaleźć pod adresem: ftp://ftp.helion.pl/przyklady/noapie.zip Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/noapie Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treści Wprowadzenie ................................................................................................................... 13 Dlaczego należy przeczytać tę książkę? Co trzeba wiedzieć, aby jak najwięcej skorzystać z tej książki? Jakie informacje zawiera ta książka? Wstęp ................................................................................................................................ 17 17 18 19 Część I. Podstawy ......................................................................................................................19 Część II. Praktyczne programowanie API .............................................................................20 Część III. Podstawowe zasady Web API ................................................................................20 20 21 22 Konwencje zastosowane w książce Użycie przykładowych kodów Podziękowania HTTP Architektura sieci Rozdział 1. Internet, World Wide Web i HTTP ........................................................................ 23 24 Zasób ...........................................................................................................................................25 URI ..............................................................................................................................................25 Cool URI ....................................................................................................................................26 Reprezentacja .............................................................................................................................26 Typ danych .................................................................................................................................27 29 Wykraczamy poza HTTP 1.1 ..................................................................................................29 Wymiana komunikatów HTTP ..............................................................................................30 Pośredniki ..................................................................................................................................32 Rodzaje pośredników ...............................................................................................................33 Metody HTTP ............................................................................................................................33 Nagłówki ....................................................................................................................................36 Kody stanu HTTP .....................................................................................................................37 Negocjacja treści ........................................................................................................................38 Buforowanie ...............................................................................................................................38 Uwierzytelnianie .......................................................................................................................42 3 Poleć książkęKup książkę Schematy uwierzytelniania ...................................................................................................... 42 Dodatkowe schematy uwierzytelniania ................................................................................. 43 44 Podsumowanie Co to jest Web API? Co w kwestii usług sieciowych SOAP? Korzenie Web API Początek rewolucji Web API Zwrócenie uwagi na sieć Wskazówki dla Web API Typy danych charakterystyczne dla domeny Profile typów danych Wiele reprezentacji Style API Rozdział 2. Web API ............................................................................................................. 45 45 45 46 46 47 47 48 49 50 51 Model dojrzałości Richardsona .............................................................................................. 52 RPC (poziom 0 w modelu dojrzałości Richardsona) ........................................................... 52 Zasoby (poziom 1 w modelu dojrzałości Richardsona) ...................................................... 54 Metody HTTP (poziom 2 w modelu dojrzałości Richardsona) ......................................... 56 Pokonanie przepaści na drodze ku API zorientowanemu na zasoby ................................ 58 Hipermedia (poziom 3 w modelu dojrzałości Richardsona) ............................................. 58 REST ........................................................................................................................................... 63 Ograniczenia REST .................................................................................................................. 63 65 Podsumowanie Najczęściej spotykane scenariusze Rozdział 3. Podstawy ASP.NET Web API ................................................................................ 67 67 Pierwsza klasa programowania HTTP .................................................................................. 68 Jednakowe możliwości podczas programowania po stronie klienta i serwera ................ 69 Elastyczna obsługa różnych formatów .................................................................................. 70 Nigdy więcej „tworzenia kodu z nawiasami ostrymi” ......................................................... 70 Możliwość stosowania testów jednostkowych ...................................................................... 70 Wiele opcji w zakresie hostingu ............................................................................................. 71 72 75 Plik WebApiConfig.cs .............................................................................................................. 76 Plik ValuesController.cs .......................................................................................................... 78 79 Utworzenie usługi ..................................................................................................................... 79 Klient .......................................................................................................................................... 86 Host ............................................................................................................................................ 86 87 Rozpoczęcie pracy z ASP.NET Web API Nowy projekt Web API „Witaj, Web API!” Podsumowanie 4 (cid:95) Spis treści Poleć książkęKup książkę Warstwa hostingu Warstwa potoku procedur obsługi komunikatów Rozdział 4. Architektura przetwarzania ................................................................................ 89 91 93 Obsługa tras ...............................................................................................................................95 96 Klasa bazowa ApiController ....................................................................................................97 103 Warstwa obsługi kontrolera Podsumowanie Cele aplikacji Model informacji Dlaczego ewolucja? Rozdział 5. Aplikacja ...........................................................................................................105 106 Bariery na drodze ewolucji ................................................................................................... 107 Jaki jest koszt zmiany? ........................................................................................................... 108 Dlaczego po prostu nie wersja? ............................................................................................ 110 Przystępujemy do pracy ........................................................................................................ 113 113 Cele ........................................................................................................................................... 113 Możliwości .............................................................................................................................. 114 114 Subdomeny ............................................................................................................................. 115 Powiązane zasoby ................................................................................................................... 116 Grupy atrybutów .................................................................................................................... 117 Kolekcje grup atrybutów ....................................................................................................... 117 Model informacji kontra typ danych .................................................................................. 118 Kolekcje zgłoszeń błędów ..................................................................................................... 119 119 Zasób główny .......................................................................................................................... 119 Zasoby wyszukiwania danych .............................................................................................. 120 Kolekcja zasobów ................................................................................................................... 120 Zasób elementu ...................................................................................................................... 120 123 Modele zasobów Podsumowanie Samoopisywanie się Rodzaje kontraktów Typy danych Rozdział 6. Projekt i wybór typu danych ..............................................................................125 125 126 126 Proste formaty ........................................................................................................................ 126 Popularne formaty ................................................................................................................. 128 Nowe formaty ......................................................................................................................... 129 Typy hipermediów ................................................................................................................. 131 Eksplozja typów danych ........................................................................................................ 132 Ogólne typy danych i profile ................................................................................................ 132 Inne typy hipermediów ......................................................................................................... 136 Spis treści (cid:95) 5 Poleć książkęKup książkę Typy relacji łączy Opracowanie nowych relacji łączy Opracowanie kontraktu nowego typu danych 137 Semantyka ................................................................................................................................137 Zastąpienie osadzonych zasobów .........................................................................................139 Warstwa pośrednia .................................................................................................................139 Dane odwołania ......................................................................................................................140 Przepływ zdarzeń w aplikacji ................................................................................................141 Składnia ....................................................................................................................................142 Doskonałe połączenie ............................................................................................................145 145 Wybór formatu .......................................................................................................................145 Włączenie obsługi hipermediów ..........................................................................................146 Opcjonalne, obowiązkowe, pominięte, stosowalne ...........................................................147 Metadane osadzone kontra zewnętrzne ..............................................................................148 Rozszerzalność ........................................................................................................................148 Rejestracja typu danych .........................................................................................................150 151 Standardowe relacje łącza ......................................................................................................151 Rozszerzenia relacji łączy ......................................................................................................152 Osadzone relacje łączy ...........................................................................................................152 Rejestracja relacji łącza ...........................................................................................................153 153 Lista zasobów ..........................................................................................................................153 Zasób elementu .......................................................................................................................155 Zasób wykrycia .......................................................................................................................156 Zasób wyszukiwania ...............................................................................................................157 157 Typy danych w domenie monitorowania zgłoszeń błędów Podsumowanie Projekt Pobranie kodu źródłowego Przygotowanie implementacji w stylu BDD Nawigacja po rozwiązaniu Pakiety i biblioteki Samohostowanie Modele i usługi Rozdział 7. Tworzenie API .................................................................................................. 159 159 160 160 161 161 162 163 Zgłoszenie błędu i magazyn dla zgłoszeń błędów ..............................................................163 Klasa IssueState .......................................................................................................................164 Klasa IssuesState .....................................................................................................................164 Klasa Link ................................................................................................................................166 Klasa IssueStateFactory ..........................................................................................................166 Klasa LinkFactory ...................................................................................................................167 Klasa IssueLinkFactory ..........................................................................................................168 6 (cid:95) Spis treści Poleć książkęKup książkę Kryteria akceptacji Funkcjonalność: pobieranie zgłoszeń błędów Funkcjonalność: tworzenie zgłoszenia błędu Funkcjonalność: uaktualnianie zgłoszenia błędu 169 172 Pobieranie zgłoszenia błędu ................................................................................................. 174 Pobieranie otwartych i zamkniętych zgłoszeń błędów ..................................................... 177 Pobieranie nieistniejącego zgłoszenia błędu ...................................................................... 179 Pobieranie wszystkich zgłoszeń błędów .............................................................................. 179 Pobieranie wszystkich zgłoszeń błędów jako danych w formacie Collection+Json ..... 182 Zasoby wyszukiwania ............................................................................................................ 184 186 188 Uaktualnianie zgłoszenia błędu ........................................................................................... 188 Uaktualnianie nieistniejącego zgłoszenia błędu ................................................................ 190 191 Usuwanie zgłoszenia błędu ................................................................................................... 191 Usuwanie nieistniejącego zgłoszenia błędu ........................................................................ 192 193 Testy ......................................................................................................................................... 193 Implementacja ........................................................................................................................ 194 195 Funkcjonalność: przetwarzanie zgłoszenia błędu Funkcjonalność: usuwanie zgłoszenia błędu Podsumowanie Rozdział 8. Usprawnianie API ..............................................................................................197 197 198 200 202 Kryteria akceptacji dla nowych funkcjonalności Implementacja obsługi buforowania danych wyjściowych Dodanie testów do sprawdzenia buforowania danych wyjściowych Implementacja ponownego pobierania buforowanych danych Implementacja warunkowych żądań GET do obsługi ponownego pobierania buforowanych danych Wykrywanie konfliktów Implementacja wykrywania konfliktów Audyt zmiany Implementacja audytu zmian za pomocą uwierzytelniania Hawk Monitorowanie Implementacja monitorowania Podsumowanie 203 206 206 209 210 213 214 216 Biblioteki klienta Rozdział 9. Tworzenie klienta ..............................................................................................217 218 Biblioteki opakowujące ......................................................................................................... 218 Łącza jako funkcje .................................................................................................................. 222 227 Warto wiedzieć ....................................................................................................................... 228 Przebieg działania aplikacji Spis treści (cid:95) 7 Poleć książkęKup książkę Klienty z misją .........................................................................................................................232 Stan klienta ..............................................................................................................................234 235 Podsumowanie Komunikaty Nagłówki Zawartość komunikatu Rozdział 10. Model programowania HTTP ........................................................................... 237 238 242 247 Wykorzystanie zawartości komunikatu ..............................................................................248 Tworzenie zawartości komunikatu ......................................................................................250 257 Podsumowanie Hosting WWW Samohostowanie Rozdział 11. Hosting .......................................................................................................... 259 260 Infrastruktura ASP.NET ........................................................................................................260 Routing ASP.NET ...................................................................................................................262 Routing Web API ...................................................................................................................264 Konfiguracja globalna ............................................................................................................266 Procedura obsługi Web API ASP.NET ...............................................................................268 270 Architektura WCF ..................................................................................................................271 Klasa HttpSelfHostServer ......................................................................................................272 Klasa SelfHostConfiguration ................................................................................................273 Rezerwacja adresu URL i kontrola dostępu ........................................................................275 275 OWIN .......................................................................................................................................276 Projekt Katana .........................................................................................................................277 Konfiguracja Web API ...........................................................................................................280 Oprogramowanie pośredniczące Web API ........................................................................281 Środowisko OWIN .................................................................................................................283 284 284 290 Hosting w pamięci Hosting Azure Service Bus Podsumowanie Hosting Web API z użyciem OWIN i Katana Ogólny opis przepływu komunikatów HTTP Potok procedur obsługi komunikatów Rozdział 12. Kontrolery i routing ........................................................................................ 291 291 292 Dyspozytor ..............................................................................................................................296 HttpControllerDispatcher .....................................................................................................297 Wybór kontrolera ...................................................................................................................297 Aktywacja kontrolera .............................................................................................................301 8 (cid:95) Spis treści Poleć książkęKup książkę Potok kontrolera 302 ApiController ......................................................................................................................... 302 Model przetwarzania ApiController ................................................................................... 302 314 Podsumowanie Waga modeli w ASP.NET Web API Jak działa dołączanie modelu? Wbudowane bindery modelu Rozdział 13. Formatery i dołączanie modelu ........................................................................315 315 316 319 Implementacja ModelBindingParameterBinder ............................................................... 320 Dostawcy wartości ................................................................................................................. 320 Bindery modelu ...................................................................................................................... 323 Dołączanie modelu tylko dla adresu URI ........................................................................... 325 Implementacja FormatterParameterBinder ....................................................................... 326 Domyślny wybór HttpParameterBinding .......................................................................... 331 331 Zastosowanie w modelu atrybutów adnotacji danych ...................................................... 331 Przeglądanie wyników operacji sprawdzania poprawności ............................................. 332 334 Sprawdzanie poprawności modelu Podsumowanie Klasa HttpClient Rozdział 14. HttpClient .......................................................................................................335 335 Cykl życiowy ........................................................................................................................... 335 Opakowanie ............................................................................................................................ 336 Wiele egzemplarzy ................................................................................................................. 336 Bezpieczeństwo wątków ........................................................................................................ 337 Metody pomocnicze .............................................................................................................. 337 Zagłębiamy się w kolejne warstwy ....................................................................................... 337 Ukończone żądania nie zgłaszają wyjątków ....................................................................... 338 Zawartość jest wszystkim ...................................................................................................... 338 Przerwanie na żądanie ........................................................................................................... 339 Metoda SendAsync() ............................................................................................................. 340 341 Proxy dla procedur obsługi ................................................................................................... 342 Nieprawdziwe procedury obsługi odpowiedzi ................................................................... 343 Tworzenie wielokrotnego użytku procedur obsługi odpowiedzi .................................... 344 346 Procedury obsługi komunikatów klienta Podsumowanie Zapewnienie bezpieczeństwa transportu Użycie TLS w ASP.NET Web API Rozdział 15. Bezpieczeństwo ...............................................................................................347 347 349 Użycie TLS z hostingiem IIS ................................................................................................. 349 Użycie TLS z samohostowaniem ......................................................................................... 351 Spis treści (cid:95) 9 Poleć książkęKup książkę Uwierzytelnianie 351 Model oświadczeń ..................................................................................................................352 Pobieranie i przypisywanie aktualnego zleceniodawcy .....................................................356 Uwierzytelnienie oparte na transporcie ..............................................................................357 Uwierzytelnienie serwera ......................................................................................................357 Uwierzytelnienie klienta ........................................................................................................361 Framework uwierzytelniania HTTP ....................................................................................367 Implementacja uwierzytelniania opartego na HTTP ........................................................369 Katana, czyli oprogramowanie pośredniczące do uwierzytelniania ................................370 Aktywne i pasywne oprogramowanie pośredniczące odpowiedzialne za uwierzytelnianie ..................................................................................374 Filtry uwierzytelniania w Web API ......................................................................................375 Uwierzytelnianie oparte na tokenie .....................................................................................378 Schemat uwierzytelniania Hawk ..........................................................................................385 386 Egzekwowanie autoryzacji ....................................................................................................388 Współdzielenie zasobów między serwerami w różnych domenach ................................391 Obsługa mechanizmu CORS na platformie ASP.NET Web API ....................................393 396 Autoryzacja Podsumowanie Rozdział 16. OAuth 2.0, czyli framework uwierzytelniania ................................................... 397 399 401 402 404 406 407 409 410 411 413 416 417 Aplikacje klienta Uzyskanie dostępu do chronionych zasobów Pobranie tokenu dostępu Uprawnienia kodu autoryzacji Zakres Kanał oficjalny kontra kanał nieoficjalny Token refresh Serwer zasobów i serwer autoryzacji Przetwarzanie tokenów dostępu w ASP.NET Web API OAuth 2.0 i uwierzytelnianie Autoryzacja na podstawie zakresu Podsumowanie Testy jednostkowe Rozdział 17. Testowanie .................................................................................................... 419 419 Frameworki testów jednostkowych .....................................................................................420 Rozpoczęcie pracy z testami jednostkowymi w Visual Studio .........................................420 xUnit.NET ...............................................................................................................................422 Rola testów jednostkowych w programowaniu TDD .......................................................423 10 (cid:95) Spis treści Poleć książkęKup książkę Testy jednostkowe implementacji ASP.NET Web API 427 Testy jednostkowe ApiController ........................................................................................ 427 Testy jednostkowe MediaTypeFormatter ........................................................................... 433 Testy jednostkowe HttpMessageHandler ........................................................................... 436 Testy jednostkowe ActionFilterAttribute ........................................................................... 437 440 442 443 Testy jednostkowe tras Testy integracji w ASP.NET Web API Podsumowanie Dodatek A. Typy danych ......................................................................................................445 Dodatek B. Nagłówki HTTP ..................................................................................................447 Dodatek C. Negocjacja treści ................................................................................................451 451 452 Negocjacja proaktywna Negocjacja reaktywna Dodatek D. Buforowanie w działaniu ...................................................................................455 Dodatek E. Przepływ zdarzeń podczas uwierzytelniania .......................................................459 Dodatek F. Specyfikacja typu danych dla application/issue+json ..........................................463 463 463 464 464 464 Konwencje nazw Dokument zgłoszenia błędu Kwestie bezpieczeństwa Kwestie interoperacyjności Kwestie związane z IANA Dodatek G. Certyfikaty i kryptografia klucza publicznego .....................................................465 471 471 Cofnięcie certyfikatu Tworzenie testowych kluczy i certyfikatów Skorowidz ...............................................................................................................475 Spis treści (cid:95) 11 Poleć książkęKup książkę 12 (cid:95) Spis treści Poleć książkęKup książkę ROZDZIAŁ 3. Podstawy ASP.NET Web API Łatwiej wyznaczyć kurs, gdy masz pod ręką mapę. Skoro dostarczyliśmy kontekst i wyjaśniliśmy, dlaczego Web API ma tak duże znaczenie dla no- woczesnych aplikacji sieciowych, w tym rozdziale przejdziemy do pracy z ASP.NET Web API. Platforma ASP.NET Web API i nowy model programowania HTTP oferują różne możliwości w za- kresie zarówno budowy, jak i wykorzystywania Web API. Na początku przedstawimy pewne najważ- niejsze cele Web API i sposoby umożliwiające ich osiągnięcie. Następnie, analizując model pro- gramistyczny, przekonasz się, jak te możliwości są udostępniane dla Twojego kodu w ASP.NET Web API. Czy może być tutaj lepszy sposób niż przeanalizowanie kodu dostarczanego przez szablon projektu Web API w Visual Studio? Na koniec wykroczymy poza domyślny kod szablonu i przy- gotujemy nasze pierwsze Web API typu „Witaj, świecie!”. Najczęściej spotykane scenariusze ASP.NET Web API, w przeciwieństwie do wielu technologii, ma doskonale udokumentowaną i do- stępną historię (fragment znajdziesz w serwisie CodePlex1). Już na samym początku zespół odpowie- dzialny za rozwój platformy podjął decyzję o zachowaniu maksymalnej możliwej przejrzystości, aby wpływ na powstawanie produktu mogła mieć społeczność ekspertów, którzy ostatecznie będą korzystać z tego produktu do budowy rzeczywistych systemów. Oto podstawowe cele, których speł- nienie stało za utworzeniem ASP.NET: (cid:120) Pierwsza klasa programowania HTTP. (cid:120) Jednakowe możliwości podczas programowania po stronie klienta i serwera. (cid:120) Elastyczna obsługa różnych formatów. (cid:120) Nigdy więcej „tworzenia kodu z nawiasami ostrymi”. (cid:120) Możliwość stosowania testów jednostkowych. (cid:120) Wiele opcji w zakresie hostingu. 1 http://wcf.codeplex.com/ 67 Poleć książkęKup książkę To tylko najważniejsze cele, a więc nie jest to pełna lista wszystkich możliwości, jakie oferuje fra- mework. ASP.NET Web API pozwala uzyskać najlepsze połączenie różnych technologii: WCF (win- dows communication foundation) z jego nieskończenie elastyczną architekturą, obsługą klienta i ela- stycznym modelem hostingu oraz ASP.NET MVC z oferowaną przez tę platformę obsługą konwencji zamiast konfiguracji, poprawionymi możliwościami w zakresie przeprowadzania testów i funk- cjami zaawansowanymi, takimi jak dołączanie modelu i weryfikacja. Jak się przekonasz podczas lektury niniejszego rozdziału, w wyniku tego połączenia powstał framework, z którym łatwo roz- począć pracę i który można bez problemu dostosować do własnych potrzeb w miarę ich ewolucji. Pierwsza klasa programowania HTTP Kiedy budujesz nowoczesne Web API — zwłaszcza przeznaczone dla prostszych klientów, takich jak urządzenia mobilne — sukces tego API jest bardzo często powiązany z jego ekspresyjnością. Z kolei ekspresyjność Web API zależy od tego, jak dobrze radzi sobie z użyciem HTTP jako proto- kołu aplikacji. Wykorzystanie HTTP w charakterze protokołu aplikacji wykracza poza prostą obsługę żądań HTTP i generowanie odpowiedzi HTTP. Oznacza, że zachowanie zarówno aplikacji, jak i sto- jącego za nią frameworku jest nadzorowane przez kontrolę przepływu zdarzeń w HTTP i elementy danych, a nie przez pewne dane dodatkowe, które są jedynie (i przypadkowo) przekazywane za po- mocą HTTP. Spójrz na przykład na poniższe żądanie SOAP użyte do komunikacji z usługą WCF: POST http://localhost/GreetingService.svc HTTP/1.1 Content-Type: text/xml; charset=utf-8 SOAPAction: HelloWorld Content-Length: 154 s:Envelope xmlns:s= http://schemas.xmlsoap.org/soap/envelope/ s:Body HelloWorld xmlns= http://localhost/wcf/greeting / /s:Body /s:Envelope W powyższym przykładzie klient wykonuje żądanie do serwera w celu otrzymania przyjaznego komunikatu powitalnego. Jak widzisz, żądanie zostało wysłane za pomocą HTTP. Jednak w tym miejscu tak naprawdę kończy się powiązanie z protokołem HTTP. Zamiast wykorzystać metody HTTP (czasami określane mianem verbs) do przedstawienia natury akcji żądanej usługi, przyjęte tutaj podejście polega na wysyłaniu wszystkich żądań za pomocą tej samej metody HTTP POST i umiesz- czeniu szczegółów charakterystycznych dla aplikacji zarówno w zawartości żądania HTTP, jak i w niestandardowym nagłówku SOAPAction. Jak zapewne się spodziewasz, ten sam wzorzec został powtórzony w odpowiedzi wygenerowanej przez tę usługę: HTTP/1.1 200 OK Content-Length: 984 Content-Type: text/xml; charset=utf-8 Date: Tue, 26 Apr 2011 01:22:53 GMT s:Envelope xmlns:s= http://schemas.xmlsoap.org/soap/envelope/ s:Body HelloWorldResponse xmlns= http://localhost/wcf/greeting ... /HelloWorldResponse /s:Body /s:Envelope 68 (cid:95) Rozdział 3. Podstawy ASP.NET Web API Poleć książkęKup książkę Podobnie jak w przypadku komunikatu żądania, elementy protokołu użyte do kontrolowania aplikacji — to znaczy określenia sposobu, w jaki aplikacje klienta i serwer mogą się wzajemnie ro- zumieć — zostały wyodrębnione z elementów HTTP i umieszczone w znacznikach XML części głównej odpowiednio żądania i odpowiedzi. W tego rodzaju podejściu HTTP nie jest używany do wyrażenia protokołu aplikacji, ale raczej po prostu jako sposób transportu dla innego protokołu aplikacji — tutaj SOAP. Wprawdzie takie rozwiązanie może być dobre w sytuacji, gdzie pojedyncza usługa musi się komunikować z podobny- mi klientami za pomocą wielu różnych protokołów, to jednak stanie się problematyczne, gdy zaj- dzie potrzeba komunikacji z wieloma różnymi klientami za pomocą pojedynczego protokołu. Pro- blemy te są doskonale zilustrowane w przypadku Web API, gdzie różnorodność nie dotyczy jedynie klientów, ale także infrastruktury komunikacyjnej między klientami i usługami (na przykład in- ternet), a ponadto ta różnorodność jest ogromna i ciągle się zmienia. W takim świecie należy dążyć do optymalizacji klientów i usług nie pod względem niezależności od protokołu, lecz raczej do zapewnienia pierwszorzędnego wrażenia dotyczącego najczęściej stosowanego protokołu aplikacji. W przypadku aplikacji komunikujących się przez sieć tym protokołem jest HTTP. Można powiedzieć, że ASP.NET Web API zbudowano na podstawie niewielkiego zbioru prostych obiektów HTTP. Dwa najważniejsze z nich to HttpRequestMessage i HttpResponseMessage. Przezna- czeniem tych obiektów jest dostarczenie silnie typowanego widoku rzeczywistego komunikatu HTTP. Spójrz na przedstawiony poniżej komunikat żądania HTTP: GET http://localhost:50650/api/greeting HTTP/1.1 Host: localhost:50650 accept: application/json if-none-match: 1 Przyjmując założenie, że pokazane żądanie zostało otrzymane przez usługę ASP.NET Web API, możemy uzyskać dostęp do różnych elementów żądania i operować nimi za pomocą przedsta- wionego poniżej kodu w klasie kontrolera Web API: var request = this.Request; var requestedUri = request.RequestUri; var requestedHost = request.Headers.Host; var acceptHeaders = request.Headers.Accept; var conditionalValue = request.Headers.IfNoneMatch; Ten silnie typowany model przedstawia poprawny poziom abstrakcji poprzez HTTP, pozwala programiście na bezpośrednią pracę z żądaniem lub odpowiedzią HTTP i jednocześnie odciąża go od konieczności zajmowania się niskiego poziomu kwestiami, takimi jak analiza nieprzetworzonego komunikatu lub jego generowanie. Jednakowe możliwości podczas programowania po stronie klienta i serwera Jednym z najbardziej kuszących aspektów związanych ze zbudowaniem ASP.NET Web API na podstawie biblioteki opartej na HTTP jest to, że biblioteka ta może być używana nie tylko przez serwer, ale również w aplikacjach klienta utworzonych z wykorzystaniem platformy .NET. To oznacza, że przedstawione wcześniej żądanie HTTP można utworzyć za pomocą tych samych klas modelu programowania HTTP, które ostatecznie będą używane do pracy z żądaniem wewnątrz Web API, co pokażemy w dalszej części rozdziału. Najczęściej spotykane scenariusze (cid:95) 69 Poleć książkęKup książkę Jak się przekonasz w rozdziale 10., model programowania HTTP to znacznie więcej niż operowanie różnymi elementami danych w żądaniach i odpowiedziach. Funkcje takie jak procedury obsługi komunikatów i negocjacja treści zostały bezpośrednio wbudowane w model programowania HTTP. To umożliwia programistom wykorzystanie ich po stronie zarówno serwera, jak i klienta w celu opracowania zaawansowanych interakcji klient – serwer przy jednoczesnej maksymalizacji wielo- krotnego użycia tego samego kodu. Elastyczna obsługa różnych formatów Szczegółowe omówienie negocjacji treści znajdziesz w rozdziale 13. W tym miejscu powinieneś wiedzieć, że na wysokim poziomie to jest proces, w którym klient i serwer współpracują ze sobą w celu określenia odpowiedniego formatu, który będzie używany podczas wymiany reprezentacji przez HTTP. Istnieje kilka różnych podejść i technik stosowanych podczas negocjacji treści. Do- myślnie ASP.NET Web API obsługuje podejście oparte na serwerze, używając nagłówka HTTP Accept, aby pozwolić klientowi na wybór między formatami XML i JSON. W przypadku braku nagłówka Accept ASP.NET Web API będzie domyślnie zwracać dane w formacie JSON (podobnie jak wiele innych aspektów frameworku, także to zachowanie domyślne można zmienić). Na przykład spójrz na poniższe żądanie do usługi ASP.NET Web API: GET http://localhost:50650/api/greeting HTTP/1.1 Ponieważ żądanie to nie zawiera nagłówka Accept wskazującego serwerowi preferowany format danych, serwer zwróci dane w formacie JSON. To zachowanie można zmienić przez umieszczenie w żądaniu nagłówka Accept i wskazanie, że preferowany typ danych to XML2: GET http://localhost:50650/api/greeting HTTP/1.1 accept: application/xml Nigdy więcej „tworzenia kodu z nawiasami ostrymi” Wraz z dojrzewaniem frameworku .NET jedno z najczęściej powtarzających się zastrzeżeń ze strony programistów dotyczyło ilości kodu konfiguracyjnego XML koniecznego do stworzenia wydawało- by się prostych lub nawet domyślnych scenariuszy. Co gorsza, ponieważ konfiguracja kontrolo- wała aspekty takie jak typy wczytywane podczas uruchamiania aplikacji, zmiana konfiguracji mogła prowadzić do błędów w systemie niewychwytywanych przez kompilator, a ujawniających się do- piero po uruchomieniu aplikacji. Jeden z największych przykładów takich narzekań wiąże się z po- przednikiem ASP.NET Web API, czyli WCF. Wprawdzie w samym WCF znacznie poprawiono kwestię konfiguracji i ilości wymaganego przez nią kodu, ale zespół odpowiedzialny za rozwój ASP.NET Web API poszedł w zupełnie innym kierunku i wprowadził tryb konfiguracji całkowicie oparty na kodzie. Szczegółowe omówienie konfiguracji ASP.NET Web API znajdziesz w rozdziale 11. 2 Utrzymywany przez IANA katalog publicznych typów danych znajdziesz tutaj: http://www.iana.org/assignments/ media-types/media-types.xhtml. 70 (cid:95) Rozdział 3. Podstawy ASP.NET Web API Poleć książkęKup książkę Możliwość stosowania testów jednostkowych Wraz z coraz większą popularnością technik takich jak TDD (test-driven development) i BDD (behavior-driven development) nastąpił także proporcjonalny wzrost frustracji związanej z faktem, że wiele popularnych usług i frameworków sieciowych nadal używa statycznych obiektów kontekstu, zamkniętych typów i obszernych drzew dziedziczenia. Te techniki znacznie utrudniają przepro- wadzanie testów jednostkowych we wspomnianych obiektach, ponieważ trudno jest je utworzyć i zainicjalizować poza środowiskiem uruchomieniowym. Na dodatek bardzo trudno jest je zastąpić „imitacjami”, które mogłyby zapewnić lepszą izolację testu. Na przykład ASP.NET bardzo mocno opiera się na obiekcie HttpContext, podczas gdy w przypad- ku WCF podstawą jest obiekt OperationContext (lub WebOperationContext, w zależności od rodzaju usługi). Podstawowy problem ze statycznymi obiektami kontekstu takimi jak wymienione polega na tym, że są one definiowane i używane przez środowisko uruchomieniowe frameworku. Dlatego też przetestowanie usługi opracowanej z użyciem tych obiektów kontekstu w rzeczywistości wy- maga uruchomienia hosta usługi i udostępnienia tej usługi. Wprawdzie tego rodzaju techniki są ogólnie rzecz biorąc akceptowane podczas testów integracji, ale okazują się nieodpowiednie do stylu programowania takiego jak TDD, który opiera się na możliwości szybkiego wykonywania małych testów jednostkowych. Jednym z celów w ASP.NET Web API jest znaczna poprawa obsługi wspomnianych powyżej stylów programowania. Mamy dwie cechy charakterystyczne frameworku pomagające w osiągnięciu tego celu. Pierwsza: ASP.NET Web API stosuje ten sam model programowania jak w przypadku frame- worku MVC. Tym samym dostępne od kilku lat możliwości w zakresie przeprowadzania testów stają się dostępne także w ASP.NET Web API. Programiści mogą więc uniknąć konieczności użycia statycznych obiektów kontekstu i opakowań, aby egzemplarze „imitacji” mogły być wykorzystywane w testach jednostkowych. Druga: pamiętaj o zbudowaniu ASP.NET Web API na podstawie modelu programowania HTTP. W tego rodzaju modelu obiekty są prostymi strukturami danych, które mogą być tworzone, kon- figurowane, przekazywane metodzie akcji jako parametr i analizowane po ich otrzymaniu w od- powiedzi. Zyskujemy więc możliwość opracowywania testów jednostkowych w jasny i konkretny sposób. Wraz z ewolucją ASP.NET Web API testowanie stało się ważnym obszarem zaintereso- wania twórców frameworku, co znajduje odzwierciedlenie w klasie HttpRequestContext w Web API 2. Dokładne omówienie tematu testowania znajdziesz w rozdziale 17. Wiele opcji w zakresie hostingu Pomimo ogólnie mniejszych możliwości jednym z największych atrybutów WCF była możliwość „samohostowania”, czyli uruchomienia w dowolnym procesie, na przykład w usłudze Windows, aplikacji działającej w konsoli lub w serwerze IIS (internet information services). Tak naprawdę ta ogromna elastyczność w zakresie hostingu powodowała, że ograniczenia w zakresie testów jednost- kowych były do zniesienia… prawie. Podczas konsolidacji WCF Web API z ASP.NET w celu utworzenia ASP.NET Web API zespół odpowiedzialny za platformę chciał zachować ową możliwość samohostowania. Dlatego usługi ASP.NET Web API, podobnie jak usługi WCF, mogą być uruchamiane w dowolnym procesie. Tematem hostingu zajmiemy się w rozdziale 11. Najczęściej spotykane scenariusze (cid:95) 71 Poleć książkęKup książkę Rozpoczęcie pracy z ASP.NET Web API Po omówieniu celów kryjących się za opracowaniem ASP.NET Web API możemy przystąpić do zapoznawania się z wybranymi elementami, z którymi będziemy pracować podczas tworzenia własnych Web API. Jedno z najprostszych podejść polega na utworzeniu zupełnie nowego pro- jektu ASP.NET Web API i przeanalizowaniu kodu dostarczanego przez szablon projektu. Aby utworzyć nowy projekt ASP.NET Web API, po uruchomieniu Visual Studio przejdź do kategorii Visual C#/Sieć Web w oknie dialogowym Nowy projekt, a następnie wybierz Aplikacja sieci Web platformy ASP.NET (rysunek 3.1). Rysunek 3.1. Projekt aplikacji ASP.NET MVC w oknie dialogowym Nowy projekt wyświetlonym w Visual Studio 2015 Po kliknięciu przycisku OK zostanie wyświetlone kolejne okno dialogowe, w którym będzie można wybrać odpowiednią konfigurację projektu. W omawianym przykładzie wybierz utworzenie pro- jektu Web API (rysunek 3.2). Zwróć uwagę na fakt, że Web API to po prostu odmiana szablonu projektu z rodziny projektów ASP.NET. Oznacza to, że projekty Web API współdzielą te same podstawowe komponenty, jak w przypadku innych typów projektów sieciowych. Różnica polega jedynie na plikach generowanych przez szablon w chwili tworzenia projektu początkowego. Dlatego jest zarówno prawidłowe, jak i możliwe dołączanie Web API w innym dowolnym szablonie pokazanym na rysunku 3.2. 72 (cid:95) Rozdział 3. Podstawy ASP.NET Web API Poleć książkęKup książkę Rysunek 3.2. Wybór Web API jako typu dla tworzonej aplikacji ASP.NET MVC Tak naprawdę ASP.NET Web API to po prostu zbiór klas utworzonych na podstawie kompo- nentów frameworku Web API i hostowanych przez proces, w którym znajduje się środowisko uruchomieniowe ASP.NET. To może być ustawienie domyślne lub wskazany przez programistę niestandardowy host (do tego tematu jeszcze powrócimy w dalszej części rozdziału). Web API moż- na więc dołączyć do dowolnego typu projektu, niezależnie od tego, czy to będzie projekt MVC, aplikacja działająca w konsoli czy nawet klasa biblioteki, do której odwołania będą pochodzić z wielu innych projektów. Komponenty frameworku ASP.NET są dostępne dla projektów Web API za pomocą aplikacji prze- znaczonej do zarządzania pakietami NuGet3. Pakiety NuGet wymienione w tabeli 3.1 są instalo- wane w domyślnym szablonie projektu. Jeżeli obsługę Web API chcesz dodać do innego projektu, musisz się po prostu upewnić, czy zainstalowałeś pakiety, które dostarczają wymaganą funkcjo- nalność. 3 http://docs.nuget.org/ Rozpoczęcie pracy z ASP.NET Web API (cid:95) 73 Poleć książkęKup książkę Tabela 3.1. Pakiety NuGet dla ASP.NET Web API Nazwa pakietu Biblioteki klienta HTTP na platformie Microsoft .NET Framework 4 Identyfikator pakietu4 Microsoft.Net.Http Microsoft ASP.NET Web API Microsoft.AspNet. (cid:180)WebApi Biblioteki klienta Microsoft ASP.NET Web API Microsoft.AspNet. (cid:180)WebApi.Client Biblioteki podstawowe Microsoft ASP.NET Web API Microsoft.AspNet. (cid:180)WebApi.Core Microsoft ASP.NET Web API Web Host Microsoft.AspNet. (cid:180)WebApi.WebHost Opis Zapewnia podstawowy model programowania HTTP, (cid:293)(cid:233)cznie z obs(cid:293)ug(cid:233) obiektów HttpRequest (cid:180)Message i HttpResponsemessage. Metapakiet6 NuGet zapewnia pojedyncze odwo(cid:293)anie do instalacji wszystkiego, co jest potrzebne do tworzenia i hostingu Web API w ASP.NET. Zawiera rozszerzenia dla podstawowych bibliotek klienta HTTP w NET Framework 4. Rozszerzenia te dostarczaj(cid:233) obs(cid:293)ug(cid:253) funkcji takich jak formatowanie XML i JSON, a tak(cid:348)e mo(cid:348)liwo(cid:316)(cid:235) przeprowadzania negocjacji tre(cid:316)ci. Zawiera podstawowy model programowania Web API i komponenty (cid:316)rodowiska uruchomieniowego, mi(cid:253)dzy innymi kluczow(cid:233) klas(cid:253) ApiController. Zawiera wszystkie komponenty (cid:316)rodowiska uruchomieniowego niezb(cid:253)dne do hostingu Web API w trakcie dzia(cid:293)ania aplikacji ASP.NET. Zale(cid:348)no(cid:316)ci pakietu5 brak Microsoft.AspNet. (cid:180)WebApi.WebHost Microsoft.Net. (cid:180)HttpNewtonsoft.Json7 Microsoft.AspNet. (cid:180)WebApi.Client Microsoft.Web. (cid:180)Infrastructure Microsoft.AspNet. (cid:180)WebApi.Core Poza pakietami NuGet instalowanymi jako część domyślnych szablonów projektów dostępne są jeszcze inne pakiety NuGet, wymienione w tabeli 3.2. Tabela 3.2. Dodatkowe pakiety NuGet dostępne dla ASP.NET Web API Nazwa pakietu Samohostowanie Microsoft ASP.NET Web API Identyfikator pakietu Microsoft.AspNet.WebApi. (cid:180)SelfHost Microsoft ASP.NET Web API OWIN Microsoft.AspNet.WebApi. (cid:180)Owin Opis Zawiera wszystkie komponenty (cid:316)rodowiska uruchomieniowego niezb(cid:253)dne do hostingu Web API w procesie klienta (na przyk(cid:293)ad aplikacji konsoli). Umo(cid:348)liwia hosting ASP.NET Web API w obr(cid:253)bie serwera OWIN i dost(cid:253)p do dodatkowych elementów serwera OWIN. Zale(cid:348)no(cid:316)(cid:235) pakietu Microsoft.AspNet. (cid:180)WebApi.Core Microsoft.AspNet. (cid:180)WebApi.Core, Microsoft.Owin, Owin 4 Identyfikator pakietu można wykorzystać do uzyskania dokładniejszych informacji o danym pakiecie. W tym celu identyfikator należy dołączyć do adresu URL. 5 Zależność pakietu NuGet oznacza, że podczas instalacji danego pakietu menedżer NuGet w pierwszej kolejności pró- buje zainstalować wszystkie pakiety, na których opiera się działanie danego pakietu. 6 Metapakiet NuGet to pakiet pozbawiony rzeczywistej zawartości i mający jedynie zależności względem innych pakietów NuGet. 7 Wprawdzie używany w ASP.NET Web API, ale NewtonsoftJson to zewnętrzny komponent, który można pobrać bez- płatnie (http://www.nuget.org/packages/newtonsoft.json). 74 (cid:95) Rozdział 3. Podstawy ASP.NET Web API Poleć książkęKup książkę Przedstawienie zbioru pakietów NuGet w postaci graficznej może pomóc w jeszcze łatwiejszym ustaleniu, które pakiety należy zainstalować w projekcie w zależności od jego celów. Przykład znajdziesz na rysunku 3.3. Rysunek 3.3. Hierarchia pakietów NuGet dla Web API Jak widać na rysunku 3.3, instalacja dowolnego z tych pakietów NuGet automatycznie spowoduje instalację wszystkich bezpośrednio lub pośrednio powiązanych z nim pakietów. Na przykład Microsoft.AspNet.WebApi spowoduje instalację pakietów Microsoft.AspNet.WebApi.WebHost, Microsoft. (cid:180)AspNet.WebApi.Core, Microsoft.Web.Infrastructure, Microsoft.AspNet.WebApi.Client, Newtonsoft.Json i Microsoft.Net.Http. Nowy projekt Web API Po utworzeniu nowego projektu ASP.NET Web API warto przeanalizować kluczowe kompo- nenty wygenerowane przez szablon projektu, które później dostosujemy do własnych potrzeb w celu utworzenia Web API. Skoncentrujemy się tutaj na dwóch ważnych plikach: WebApiConfig.cs i ValuesController.cs (rysunek 3.4). Nowy projekt Web API (cid:95) 75 Poleć książkęKup książkę Rysunek 3.4. Pliki WebApiConfig.cs i ValuesController.cs zaznaczone w oknie Eksploratora rozwiązania w Visual Studio 2015 Plik WebApiConfig.cs Plik C# lub Visual Basic.NET znajduje się w katalogu App_Start i deklaruje klasę WebApiConfig. Ta klasa zawiera pojedynczą metodę o nazwie Register() i jest wywoływana przez kod metody Application_Start() w pliku global.asax. Jak sama nazwa wskazuje, klasa jest odpowiedzialna za rejestrację różnych aspektów konfiguracji Web API. Domyślnie podstawowy kod konfiguracyjny wygenerowany przez szablon projektu powoduje zarejestrowanie domyślnej trasy Web API. Trasa ta jest używana do mapowania przychodzących żądań HTTP na klasy kontrolerów, a także do prze- twarzania elementów danych, które mogą być wysyłane jako część adresów URL i udostępniane innym klasom w potoku przetwarzania. Kod domyślnej klasy WebApiConfig przedstawiliśmy w li- stingu 3.1. Listing 3.1. Kod domyślnej klasy WebApiConfig public static class WebApiConfig { public static void Register(HttpConfiguration config) { // Konfiguracja i us(cid:225)ugi sk(cid:225)adnika Web API // Skonfiguruj sk(cid:225)adnik Web API, aby korzysta(cid:225) tylko z uwierzytelniania za pomoc(cid:261) tokenów bearer config.SuppressDefaultHostAuthentication(); config.Filters.Add(new HostAuthenticationFilter(OAuthDefaults.AuthenticationType)); // Trasy sk(cid:225)adnika Web API config.MapHttpAttributeRoutes(); 76 (cid:95) Rozdział 3. Podstawy ASP.NET Web API Poleć książkęKup książkę config.Routes.MapHttpRoute( name: DefaultApi , routeTemplate: api/{controller}/{id} , defaults: new { id = RouteParameter.Optional } ); } } Jeżeli programowanie w stylu MVC nie jest Ci obce, wówczas możesz dostrzec, że ASP.NET Web API oferuje odmienny zbiór metod rozszerzających do zarejestrowania swoich tras innych niż do- myślne trasy MVC. Na przykład ten sam nowy projekt zawierający klasę WebApiConfig zawiera także klasę RouteConfig, której kod przedstawia się następująco: public class RouteConfig { public static void RegisterRoutes(RouteCollection routes) { routes.IgnoreRoute( {resource}.axd/{*pathInfo} ); routes.MapRoute( name: Default , url: {controller}/{action}/{id} , defaults: new { controller = Home , action = Index , id = UrlParameter.Optional } ); } } Istnienie dwóch metod przeznaczonych do konfiguracji tras może się na początku wydawać nie- potrzebne i dlatego też warto omówić występujące między nimi różnice na wysokim poziomie. Trzeba pamiętać, że te metody „mapujące” to po prostu metody rozszerzające odpowiedzialne za utworzenie egzemplarza trasy i jego dodanie do kolekcji tras powiązanej z hostem. Różnica między tymi metodami i zarazem powód istnienia obu sprowadza się do faktu, że ASP.NET MVC i ASP.NET Web API używają zupełnie różnych klas tras, a nawet typów kolekcji tras. Szczegóły dotyczące wspomnianych typów omówimy bardzo dokładnie w rozdziale 11. Powodem zastosowania innego typu tras niż w ASP.NET MVC było umożliwienie ASP.NET Web API odcięcie się od starego kodu znajdującego się w klasach Route i RouteCollection w podzespole System.Web, a tym samym za- pewnienie znacznie większej elastyczności pod względem opcji dotyczących hostingu. Pośrednią korzyścią wynikającą z tej decyzji projektowej jest dostarczenie ASP.NET Web API możliwości samohostowania. Konfiguracja routingu ASP.NET Web API wymaga zadeklarowania egzemplarzy HttpRoute i do- dania ich do kolekcji tras. Pomimo tworzenia egzemplarzy HttpRoute za pomocą innej metody rozszerzającej niż w przypadku ASP.NET MVC semantyka pozostała praktycznie identyczna, między innymi w zakresie elementów takich jak nazwa trasy, szablon trasy, parametry domyślne, a nawet ograniczenia trasy. Jak możesz zobaczyć w listingu 3.1, wygenerowany przez szablon projektu kod konfiguracyjny tras definiuje trasę domyślną dla API zawierającą prefiks api w adresie URI, nazwę kontrolera i opcjonalny parametr w postaci identyfikatora. Bez konieczności wprowadzania jakich- kolwiek modyfikacji ta deklaracja trasy zwykle okazuje się wystarczająca do tworzenia API po- zwalającego na pobieranie, uaktualnianie i usuwanie danych. Taka możliwość wynika ze sposobu, w jaki klasa kontrolera ASP.NET Web API mapuje metody HTTP na metody akcji kontrolera. Mapowaniem metod HTTP zajmiemy się dokładniej w dalszej części rozdziału, natomiast szcze- gółowe omówienie tego tematu znajdziesz w rozdziale 12. Nowy projekt Web API (cid:95) 77 Poleć książkęKup książkę Plik ValuesController.cs Klasa ApiController będąca klasą nadrzędną dla klasy ValuesController jest sercem ASP.NET Web API. Wprawdzie można utworzyć prawidłowy kontroler ASP.NET Web API przez imple- mentację różnych elementów składowych interfejsu IHttpController, ale w praktyce większość kon- trolerów ASP.NET Web API powstaje na podstawie klasy ApiController. Ta klasa odgrywa ważną rolę podczas koordynacji pozostałych klas w modelu obiektowym ASP.NET Web API w celu przeprowadzania kilku kluczowych zadań podczas przetwarzania żądania HTTP: (cid:120) wybór i uruchomienie metody akcji w klasie kontrolera; (cid:120) konwersja elementów komunikatu żądania HTTP na parametry w metodzie akcji kontrolera i konwersja wartości metody akcji kontrolera na prawidłową część główną odpowiedzi HTTP; (cid:120) wykonanie różnego rodzaju filtrów skonfigurowanych dla metody akcji, kontrolera lub glo- balnie; (cid:120) udostępnienie odpowiedniego stanu kontekstu metodom akcji klasy kontrolera. Oparcie na klasie bazowej ApiController i wykorzystanie zalet kluczowych zadań przetwarzania żądania powoduje, że klasa ValuesController dołączona do szablonu Web API stanowi wysokiego poziomu abstrakcję zbudowaną na podstawie ApiController. W listingu 3.2 przedstawiliśmy kod domyślnej klasy ValuesController. Listing 3.2. Kod domyślnej klasy ValuesController public class ValuesController : ApiController { // GET api/values public IEnumerable string Get() { return new string[] { value1 , value2 }; } // GET api/values/5 public string Get(int id) { return value ; } // POST api/values public void Post([FromBody]string value) { } // PUT api/values/5 public void Put(int id, [FromBody]string value) { } // DELETE api/values/5 public void Delete(int id) { } } 78 (cid:95) Rozdział 3. Podstawy ASP.NET Web API Poleć książkęKup książkę Klasa ValuesController choć prosta, to jednak okazuje się niezwykle użyteczna, gdy po raz pierwszy spoglądasz na model programowania kontrolera. Przede wszystkim zwróć uwagę na nazwy metod akcji kontrolera. Domyślnie w ASP.NET Web API stosowana jest konwencja polegająca na nadaniu metodzie akcji nazwy odpowiadającej me- todzie HTTP. Ujmując rzecz dokładniej, klasa ApiController wyszukuje metodę akcji o nazwie rozpoczynającej się od odpowiedniej metody HTTP. Dlatego w kodzie przedstawionym w listingu 3.2 żądanie HTTP GET do zasobu /api/values będzie obsłużone przez pozbawioną parametrów metodę Get(). Framework oferuje różne sposoby dostosowania tej domyślnej logiki dopasowy- wania nazw i zapewnia możliwość rozbudowy mechanizmu, a nawet jego całkowite zastąpienie, jeśli istnieje potrzeba. Więcej szczegółowych informacji na temat wyboru kontrolera i akcji znaj- dziesz w rozdziale 12. Poza wyborem metody akcji na podstawie metody HTTP ASP.NET Web API pozwala również wybrać akcję na podstawie elementów dodatkowych żądania, takich jak parametry ciągu teksto- wego zapytania. Co ważniejsze, framework obsługuje dołączanie tych elementów żądania do pa- rametrów metody akcji. Domyślnie używane jest połączenie obu podejść w celu przeprowadzenia operacji dołączania parametru, a sam algorytm obsługuje zarówno proste, jak i złożone typy .NET. W przypadku odpowiedzi HTTP model programowania ASP.NET Web API umożliwia metodom akcji zwrot typów .NET i konwertuje te wartości na odpowiednią postać części głównej komunikatu odpowiedzi HTTP, używając negocjacji treści. Więcej szczegółowych informacji na temat dołącza- nia parametrów i negocjacji treści znajdziesz w rozdziale 13. Omówiliśmy już pewne aspekty projektu ASP.NET Web API, choć zaledwie dotknęliśmy tematu modelu programowania, analizując kod wygenerowany przez szablon projektu. Teraz możemy pójść nieco dalej i utworzyć nasze pierwsze Web API typu „Witaj, świecie!”. „Witaj, Web API!” Jako pierwszy przykład ASP.NET Web API utworzymy prostą usługę powitalną. Czy w świecie programowania istnieje bardziej znane powitanie niż „Witaj, świecie!”? Pracę rozpoczynamy więc od prostego, przeznaczonego tylko do odczytu API powitania, a następnie w pozostałej części rozdziału dodamy kilka usprawnień, aby tym samym zaprezentować inne aspekty modelu pro- gramowania ASP.NET Web API. Utworzenie usługi Aby zbudować usługę, zacznij od utworzenia nowej aplikacji ASP.NET z poziomu okna dialogo- wego Nowy projekt w Visual Studio. W kolejnym oknie dialogowym jako rodzaj projektu wybierz Web
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Nowoczesne API. Ewoluujące aplikacje sieciowe w technologii ASP.NET
Autor:
, , , ,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: