Początki
Nowy projekt, nowe wyzwania. Jeśli macie za sobą radosny czas planowania, projektowania i wybierania technologii, pora przystąpić do utworzenia projektu w odpowiednim środowisku deweloperskim.
REST API w Visual Studio
W moim wypadu, dosyć naturalnie wypadło na Visual Studio 2015 ze względu na moje doświadczenia oraz wybraną technologię – .Net. To co chciałbym pokazać w tym poście, to jak wiele otrzymujemy wykonując raptem kilka kliknięć i czekając niecałą minutę na załadowanie nowego projektu, ściągnięcie paczek nugetowych oraz „rozgrzanie” IISa po starcie aplikacji.
Aby utworzyć serwis typu REST, w Visualu tworząc nowy projekt wybieramy kolejno ASP.NET Web Application, a następnie template Web API. Oczywiście możemy również stworzyć pusty projekt, ale dla celów edukacyjnych warto zobaczyć, co zaoferuje nam samo IDE. Z ciekawych alternatyw mamy także oczywiście do wyboru utworzenie aplikacji webowej, czy Azure Mobile Service, za którym kryje się backend dla serwisów mobilnych.
To co ukaże się naszym oczom, to przede wszystkim pokaźna struktura projektów, w której można zauważyć podział na elementy składowe wzorca MVC, a także elementy wskazujące na obecność stronki webowej.
Poza struktury projektu, w oknie przeglądania znajduje się krótkie podsumowanie tego, co zostało właśnie utworzone oraz jakie dodatkowe kroki można zrobić dalej – deployment w Azure, czy dopasowanie aplikacji do naszych potrzeb. Visual chwali się również, z jakich elementów składa się nasza aplikacja.
Help Pages
Pierwszym elementem na liście są Help Pages, czyli automatycznie generowana dokumentacja naszego API. Znajdziemy tam zarówno endpointy poszczególnych kontrolerów i akcji, jaki i modele wejściowe i odpowiedzi serwisu. Dokumentacja ma formę stron internetowych, a opatrzenie kontrolerów i akcji odpowiednimi komentarzami w kodzie spowoduje automatyczne dodanie tych treści do naszej dokumentacji.
Bootstrap
Wraz z utworzeniem projektu, dodaje się najbardziej popularny framework (przynajmniej według jego autorów…) do tworzenia aplikacji webowych, czyli Bootstrap. Wyżej opisane strony Help Pages opierają się własnie na nim i nic nie stoi na przeszkodzie, aby w razie potrzeb kolejne strony również czerpały z niego pełnymi garściami.
Uwierzytelnianie klienta
Jednym z utworzonych dla nas kontrolerów, jest AccountController. Pod jego postacią kryje się prawie 500 linii kodu, którego zadaniem jest umożliwianie zarządzaniem kontami użytkowników: rejestracja, pobieranie informacji o użytkowniku, czy możliwość zmiany hasła. Kontrola dostępu działa w przypadku tego szablony projektu w oparciu formę autentykacji OWIN, o czym powiem więcej w kolejnym poście. OWIN to nie sama autentykacja – to przedsięwzięcie mające na celu ujednolicenie interfejsów pomiędzy serwerami działającymi w oparciu o .NET, a aplikacjami webowymi.
Nuget – last but not least
Ostatnim elementem układanki jest narzędzie do zarządzania paczkami używanymi w projekcie. Czasy, gdy utrzymywano katalogi z zależnymi binarkami dawno już minęły. W kontroli wersji przechowujemy tylko definicje zależności, a checkout projektu oraz otwarcie go w Visualu spowoduje ściągnięcie odpowiednich wersji komponentów.
Co dalej
W najbliższych postach poruszę temat autentykacji klientów w serwisie opartym o REST API, m.in. w oparciu o wspomniany wyżej OWIN. Wypadałoby również skorzystać z możliwości deploymentu aplikacji z Visuala bezpośrednio do chmury Azure, do czego zachęca sam wizard tworzenia projektu.
