Zadanie domowe 2 - pytania

[brzezinskimarcin]

Zadanie 2 jest sformułowane na tyle niejasno, że mam kilka pytań:

• jak ma zachowywać się endpoint '/login' w przypadku, gdy użytkownik jest zalogowany?
• czy to, jak wygląda numeracja ryb jest sprecyzowane? Mamy numerować "id_1", id_2", ... i rybek szukać po /fishes/id_1?format=JSON (taki URL wygląda co najmniej dziwnie)?
• co ma zawierać endpoint '/'?
• czy mamy weryfikować JSON podawany w '/fishes/' PUT, PATCH oraz '/fishes' POST pod względem poprawności, czy możemy założyć, że wprowadzane dane są poprawne?
• jeśli chcemy zmienić 'lat' u jakiejś rybki to przesłany JSON to będzie: { "where": { "lat": 0.001, } } czy może { "lat": 0.001 }

[halicki]

@brzezinskimarcin,

Zadanie dokładnie oddaje charakter pracy z klientem. Klient często sam nie wie czego tak naprawdę chce. Zazwyczaj musisz pomyśleć za niego. W tym przypadku Waszym zadaniem jest pomyślenie za prowadzących :wink:

1. jak ma zachowywać się endpoint /login w przypadku, gdy użytkownik jest zalogowany?

   Skoro zachowanie endpointu /login nie jest sprecyzowane dla przypadku w którym użytkownik jest już zalogowany, to możesz zrobić tu co tylko zechcesz. Możesz się wykazać. Nasza sprawdzarka nie będzie brała pod uwagę tego przypadku. Więc zrób tak aby było dobrze :wink: Przykładowe rozwiązania:

   • jeżeli już wcześniej zalogowany to przekieruj na /
   • jeżeli już wcześniej zalogowany to przekieruj na /hello
   • jeżeli już wcześniej zalogowany a brakuje nagłówka Authorization, to wyloguj
   • etc.

2. czy to, jak wygląda numeracja ryb jest sprecyzowane? Mamy numerować "id\_1", id\_2", ... i rybek szukać po /fishes/id_1?format=JSON (taki URL wygląda co najmniej dziwnie)?

   Pisząc "id_1", "id_2" mieliśmy na myśli przykładowe identyfikatory przyznane przez wasze systemy. W takim układzie macie pełną swobodę, jeżeli chodzi o ID'ki. Możecie użyć kolejnych indeksów z "bazy danych". O tym na kolejnych z wykładów. Jeżeli jednak pamiętasz z wykładu, co Marcin mówił, o nadawaniu id'ków obiektom to wiesz, że często warto jest to robić w sposób uniemożliwiający łatwe zgadnięcie ID obiektu. Sam zdecyduj co w przypadku systemu dla wędkarzy jest ważniejsze.

3. co ma zawierać endpoint /?

   Może zawierać dowolną treść. Tak jak wcześniej napisałem, niesprecyzowane zachowanie stanowi pole do dowolnej interpretacji przez uczestników. Przykładowe rozwiązania:

   • może przekierowywać do /fishes
   • może wyświetlać tę samą treść /fishes
   • może podawać prognozę pogody dedykowaną wędkarzom. :wink:

4. czy mamy weryfikować JSON podawany w /fishes/ PUT, PATCH oraz /fishes POST pod względem poprawności, czy możemy założyć, że wprowadzane dane są poprawne?

   To nie będzie konieczne. Na tę chwilę przyjmijmy, że dane są OK.

5. jeśli chcemy zmienić lat u jakiejś rybki to przesłany JSON to będzie:

   { 
     "where": { 
       "lat": 0.001
     } 
   }

   czy może:

   {
     "lat": 0.001
   }

   Z dwóch podanych przez Ciebie sposobów bardziej sensownym jest pierwszy dlatego, że w przyszłości może pojawić się dodatkowa informacja o współrzędnej geograficznej dla każdej rybki: np. miejsce wypuszczenia z powrotem do akwenu, albo miejsce rozrzucenia zanęty. W takim przypadku podanie tylko "lat" byłoby niejednoznaczne.

   Załóżmy jednak, że robiąć zapytania PATCH, będziemy po prostu zastępować obiekty najwyższego poziomu. W takim wypadku zastosujemy poniższy sposób:

   {
     "where": {
       "long": 1.234,
       "lat": 0.001
     }
   }

   Ciekawostka: Istnieje coś takiego jak JSON PATCH (opisane tu: http://jsonpatch.com/ i tu: https://tools.ietf.org/html/rfc6902). Ustandaryzowany sposób na robienie PATCHY JSONÓW. Ale nie będziemy tu z niego korzystać.

[brzezinskimarcin]

Dzięki za wyjaśnienia :-)