Projekt Bilet #1 — pierwsze linijki kodu

W poprzed­niej częś­ci pisal­iśmy o tym, czym jest Spring Boot oraz mniej więcej jakich tech­nologii będziemy uży­wać. Dzisi­aj zainicju­je­my i skon­fig­u­ru­je­my nasz pro­jekt, a także uru­chomimy pier­wszy endpoint.

Uwa­ga — w kur­sie tym pominiemy stworze­nie repozy­to­ri­um oraz korzys­tanie z Git’a — jak stworzyć własne repozy­to­ri­um oraz jak z niego korzys­tać szczegółowo opisy­wal­iśmy w osob­nym wpisie — gorą­co zachę­camy do zapoz­na­nia się z nim i pracę nad włas­nym pro­jek­tem za pomocą Gita!

Spring Initializr

Jed­nym z pier­wszych zadań jest stworze­nie szkiele­tu pro­jek­tu — stworze­nie pro­jek­tu Mavenowego, uzu­pełnie­nie zależnoś­ci, zainicjowanie aplikacji webowej itp. Nie jest to zbyt ciekawe, i na szczęś­cie Spring pozwala nam ten pro­ces uproś­cić! Pod nazwą Spring Ini­tial­izr kry­je się proste w uży­ciu narzędzie, które poz­woli wygen­erować pro­jekt o pod­sta­wowej struk­turze z zależnoś­ci­a­mi i bazową konfiguracją.

Spring Ini­tial­izr — ekran główny (i jedyny)

Dzię­ki temu wystar­czy, że wybierze­my potrzeb­ne mod­uły, uzu­pełn­imy pod­sta­wowe infor­ma­c­je (nazwę paki­etu bazowego, rodzaj pro­jek­tu, wer­sję Spring Boot itp), i będziemy mogli pobrać pod­sta­wowy wygen­erowany pro­jekt. W naszym przy­pad­ku wybierze­my mod­uły, o których wiemy, że będziemy z nich korzys­tali — Web, JPA, Secu­ri­ty, MySQL, H2 oraz Elasticsearch.

Pierwsze kroki

Nasza aplikac­ja jest już gotowa do uru­chomienia! Zaim­por­tuj ją w wybranym przez siebie środowisku ( o tym jak zro­bić to w Eclipse, pisal­iśmy w lekcji 7.1, sekc­ja ‘Impor­tuj projekt/moduł’), aby móc z nią pra­cow­ać bez przeszkód. Ter­az już nic nie stoi na przeszkodzi i może­my ją uru­chomić po pros­tu uruchami­a­jąc klasę pl.kobietydokodu.bilet.WebappApplication (uwa­ga — paki­et może się różnić, w zależnoś­ci od opcji wybranych w Spring Ini­tial­izr) tak jak każdą inną aplikację Javy. Efekt póki co nie powala na kolana — nasza aplikac­ja jeszcze nic nie robi ;) Po poda­niu loginu i hasła (login to ‘user’, a hasło jest gen­erowane losowo za każdym razem — zna­jdziesz je w logach aplikacji) widz­imy domyśl­ną stronę błędu:

Domyśl­na strona błę­du 404

Wystawiamy endpoint

W tej lekcji wys­taw­imy tylko prosty end­point — po przekaza­niu imienia, wygeneru­je­my proste przy­wi­tanie. Tworzymy więc klasę Greet­ing­Con­troller, która będzie wyglą­dała następująco:

package pl.kobietydokodu.bilet.controller;

import java.util.Optional;

import org.apache.commons.lang3.StringUtils;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/greet")
public class GreetingController {

    @RequestMapping({"", "/{person}"})
    public String greetPerson(@PathVariable(name="person", required=false) Optional<String> maybePerson) {
        String person = maybePerson.filter(StringUtils::isNotBlank).orElse("unknown person");
        return String.format("Hello %s!", person);
    }

}

Sama funkcjon­al­ność jest bard­zo pros­ta — nasza meto­da przyj­mu­je jeden (opcjon­al­ny) para­metr w adresie URL. Jeśli jest on podany (i nie­pusty), wita­my daną osobę, w prze­ci­wnym wypad­ku — wita­my niez­naną osobę. Jeśli nie pamię­tasz co dokład­nie robiła adno­tac­ja @PathVariable lub @RequestMapping, zajrzyj dla przy­pom­nienia do lekcji 9!

Wszys­tko było­by w porząd­ku, gdy­by nie to, że aplikac­ja nadal wyma­ga, abyśmy się logowali! Aby wyłączyć logowanie dla tej konkret­nej metody, musimy dodać do pliku application.properties (zna­jdziesz go w kat­a­logu src/main/resources) następu­jącą linijkę:

security.ignored=/**

Zapewne ciekawi Cie jak to dzi­ała — o tym będziemy pisać w przyszłoś­ci, póki co najważniejsze, że nasze pow­i­tanie nie wyma­ga logowa­nia się!

Testujemy nasz endpoint

Naszą aplikację może­my z powodze­niem przetestować wpisu­jąc adres bezpośred­nio w przeglą­darce — nie będzie to jed­nak możli­we jak zaczniemy tworzyć bardziej zaawan­sowane end­pointy, przyj­mu­jące obiek­ty i korzys­ta­jące z innych metod HTTP.

Pomoc­ne będzie tutaj narzędzie takie jak DHC czy Post­man (narzędzi tych ist­nieje wiele więcej, te dwa są jed­ny­mi z najpop­u­larniejszych) — w dal­szej częś­ci kur­su będziemy korzys­tać właśnie z DHC (nie wyma­ga on insta­lacji — moż­na z niego korzys­tać wprost ze strony twór­ców, ale moż­na także pobrać jako plu­g­in do Chrome, co zalecamy).

Aby przetestować nasz end­point, w okienku głównym uzu­peł­ni­amy adres URL oraz opcjon­al­nie nazwę, nagłów­ki itp. W naszym przy­pad­ku wyglą­da to tak:

Widok główny pro­gra­mu DHC

Po wysła­niu zapy­ta­nia może­my zobaczyć odpowiedź — nie tylko samą treść, ale także nagłów­ki i infor­ma­c­je pomocnicze:

Popraw­na odpowiedź na zapy­tanie HTTP — sta­tus 200

Pozostałe opc­je bardziej szczegółowo będziemy omaw­iać przy okazji imple­men­towa­nia kole­jnych funkcjon­al­noś­ci. Zaprasza­my do kole­jnych lekcji już wkrótce!

Kod źródłowy

Kody źródłowe są dostęp­ne w ser­wisie GitHub — użyj przy­cisków po prawej aby pobrać lub prze­jrzeć kod do tego mod­ułu. Jeśli masz wąt­pli­woś­ci, jak posługi­wać się Git’em, instrukc­je i lin­ki zna­jdziesz w naszym wpisie na tem­at Git’a.