Budujemy przykładową aplikację w Laravel – część 5, budujemy API

Dzisiejszy wpis poświęcony jest kolejnej części naszego systemu. Tym razem zajmiemy się budową API dostępowego, tak by w niedalekiej przyszłości połączyć się z nim za pomocą Angulara. Nasze API dotyczyć będzie przede wszystkim funkcjonalności związanych z administracją systemem. W opisywanej wersji będzie to kilkanaście metod dostępowych, wraz z rozwojem aplikacji, grupę tą poszerzymy oczywiście o kolejne, nowe żądania.

Do testowania API polecam świetny dodatek do Chrome o nazwie Postman, świetnie nadaje się do wysyłania zarówno prostych jak i bardziej rozbudowanych żądań.

Krótka analiza systemu pozwala na wybranie niezbędnych metod:

  • Rent

– getAll() – pobieranie wszystkich wypożyczeń

– getAllByVehicle() – pobieranie wszystkich rezerwacji dla konkretnego pojazdu

– accept() – akceptacja wypożyczenia przez administratora, czyli zmiana statusu na “2” – potwierdzoną rezerwację

– delete() – usunięcie rezerwacji

  • Vehicle

– store() – dodanie nowego pojazdu do bazy, w tym zapisanie zdjęcia pojazdu, a także właściciela

– getAll() – pobranie wszystkich pojazdów

– getAllByUser() – pobranie wszystkich pojazdów konkretnego użytkownika

– delete() – usunięcie pojazdu z bazy

– update() – aktualizacja pojazdu

  • User

– store() – dodanie nowego użytkownika

– getAll() – pobranie wszystkich użytkowników

– find() – pobranie danych użytkownika o konkretnym id

Przełożenie tego na plik routingu routes/api.php wygląda następująco:

Ponadto, dla każdego z modeli (Vehicle, User, Rent) potrzebujemy:

  • samego modelu (już mamy)
  • Repositories
  • obiektów Factory
  • obiektów Request do walidacji dodawania
  • Kontrolerów do API – będziemy przechowywać je w podkatalogu Api
  • Testów automatycznych

Rezerwacje

Zaczynamy od DAO:
Repositories\RentRepository.php

Dwie nowe metody to getAllByVehicle() i accept(). Pierwsza z nich to zwykłe zapytanie do bazy, natomiast accept, czyli zatwierdzenie rezerwacji najpierw odnajduje potrzebną rezerwację, po czym zmienia jej status, a na koniec dokonaną zmianę zapisuje w bazie.

Obiekt CreateRentRequest został stworzony w poprzednim odcinku, także jego listing pomijam.

Kolejny krok to kontroler:
Controllers\Api\RentController.php

Kontroler RentController zawiera 4 metody:

getAll() – pobiera wszystkie rekordy i zwraca jako JSON

getAllByVehicle() – na podstawie przekazanego za pomocą Dependency Injection $id następuje pobranie wszystkich wypożyczeń dla danego pojazdu

accept() – zatwierdzenie rezerwacji dla podanego id

delete() – usunięcie rezerwacji

Krótka próba wysłania żądania:
http://127.0.0.1:8000/api/rent/1/?api_token=mykey

w rezultacie daje:

Czyli działa! 🙂 Kolejny etap to testy automatyczne, nie zapominamy o obiekcie Fabryki:

i sam test, plik RentRepositoryTest.php:

Nasze testy sprawdzają dwa nowe elementy (reszta została otestowana wcześniej, np. dodawanie nowej rezerwacji testowaliśmy przy okazji interfejsu klienta), dla zwięzłości opisuję więc tylko nowe testy:

  • testGetAllByVehicle() – tworzymy 3 nowe wpisy o dwóch różnych vehicle_id (1 i 2). Za pomocą prywatnej metody getAllByVehicleFilteredResponse wysyłamy żądanie do serwisu i pobieramy wszelkie wypożyczenia dla id = 2. Na końcu porównujemy, czy wszystkie otrzymane wyniki faktycznie mają id =2.
  • testAccept() – dodajemy jeden nowy rekord, następnie wywołujemy metodę accept z repozytorium, pobieramy wpisy z bazy i sprawdzamy czy nasz dodany wcześniej rekord faktycznie posiada zmodyfikowany status na “2”.

Wszystko działa, testy system przechodzi bez problemów, możemy przejść dalej – do pojazdów 🙂

Pojazdy

Baza pojazdów, a przede wszystkim API dostępowe także nic odkrywczego, zajrzyjmy do naszego Repository (model już mamy):
Repositories\VehicleRepository.php

Tutaj praktycznie cały kod jest nowy, dokonajmy więc jego analizy:

  • getAll() – pobranie wszystkich pojazdów
  • getAllByUser() – pobranie wszystkich pojazdów konkretnego użytkownika
  • create() – stworzenie nowego pojazdu, zapisanie danych w modelu i bazie, zapisanie obrazka zakodowanego w base64 do pliku na serwerze
  • update() – edycja pojazdu, sprawdzenie czy nowe dane zawierają obrazek, jeśli tak to nadpisanie pliku obrazkowego

W następnej kolejności potrzebujemy obiektu Requests/CreateVehicleRequest:

Nie jest on w żaden sposób odkrywczy – dodajemy informację, że pola title, description i user_id są polami wymaganymi. Przejdźmy do kodu kontrolera:
Controllers/Api/VehicleController.php:

Konstruktor ewoluował i zawiera teraz kilka niezbędnych metod:

  • store() – zapisanie nowego pojazdu w bazie
  • getAll() – pobranie wszystkich pojazdów
  • getAllByUser() – pobranie wszystkich pojazdów konkretnego użytkownika
  • delete() – usunięcie pojazdu
  • update() – aktualizacja pojazdu

Przechodzimy do testów i tradycyjnie rozpoczynamy od fabryki, database/factories/VehicleFactory.php:

i wreszcie same testy, Unit/Repositories/VehicleRepositoryTest.php::

Testy kolejno:

  • tesGetAllByUser() – w tym teście tworzymy 3 nowe pojazdy, każdy z innym właścicielem. Następnie pobieramy z systemu wszystkie pojazdy dla usera o id = 3 i sprawdzamy czy faktycznie wszystkie z zwróconych pojazdów mają przypisanego właściciela o numerze 3.
  • testCreate() – dodajemy nowy pojazd, następnie odwołując się do systemu pobieramy listę pojazdów z bazy i sprawdzamy czy na liście istnieje wcześniej dodany wpis.
  • testUpdate() – standardowo – tworzymy nowy pojazd, następnie modyfikujemy jego model i sprawdzamy czy system zwraca poprawne, zaktualizowane dane.
  • testGetAll() – dodajemy trzy niezależne pojazdy, po czym sprawdzamy czy istnieją na liście otrzymanej z serwera.

Moduł pojazdów oprogramowany i przetestowany. Ostatni etap prac to:

Użytkownicy

Nasze repozytorium nie ulegnie zmianie, przejdźmy od razu do kontrolera:
Controllers/Api/UserController.php

Jak widzimy, kontroler realizuje podstawowe metody bazowego repozytorium: pobieranie wszystkich użytkowników, odnalezienie użytkownika, czy stworzenie nowego.

Obiekt walidacji, Requests/CreateUserRequest.php, podpowie nam, które z pól obiektu są wymagane:

Obiekt fabryki to także standardowy wpis:
database/factories/UserFactory.php

Same testy również nie wyróżniają się niczym szczególnym, Unit/Repositories/UserRepositoryTest.php:

Powyższe testy nie wprowadzają nic nowego, są to te same, klasyczne wpisy znane z Wypożyczeń i Pojazdów.

Tak oto kończymy cykl dotyczący backendu naszej aplikacji. W następnym odcinku zajmiemy się połączeniem naszego API z Angularem 5.

Podsumowanie API

Żądanie Opis
Wypożyczenia
GET /rent zwraca listę wypożyczeń
GET /rent/{id} zwraca informacje o pojedynczym wypożyczeniu
GET /rent/accept/{id} akceptuje wypozyczenie
DELETE /rent/{id} usuwa wypożyczenie
Pojazdy
POST /vehicle/{id} Aktualizuje sprzęt/pojazd
GET /vehicle Pobiera listę sprzętu/pojazdów
GET /vehicle/{id} Pobiera listę sprzętu należącego do użytkownika
POST /vehicle/store Dodaje pojazd do bazy
DELETE /vehicle/{id} Usuwa pojazd
Użytkownicy
POST /user/store Dodaje użytkownika do bazy
GET /user Zwraca listę użytkowników
GET /user/{id} Pobiera informacje o konkretnym użytkowniku

Kod źródłowy odcinka

GIT: https://gitlab.com/spooky001/kajaki

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

This site uses Akismet to reduce spam. Learn how your comment data is processed.