Closed brzezinskimarcin closed 6 years ago
@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:
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:
/
/hello
Authorization
, to wylogujczy 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.
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:
/fishes
/fishes
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.
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ć.
Dzięki za wyjaśnienia :-)
Zadanie 2 jest sformułowane na tyle niejasno, że mam kilka pytań: