[Wrath_of_the_Tyrant]

Jeżeli User posiada listę itemów które tylko on powinien móc wyświetlić, to jak to w REST lepiej zrobić?

Pierwsze rozwiązanie:
/users/{username}/items - i razem z requestem wysyłać coś, co pozwoli na potwierdzenie praw dostępu

Drugie rozwiązanie:
/items - i z requestem wysyłać dane, które pozwalają równocześnie stwierdzić o którego Usera chodzi oraz potwierdzić jego uprawnienia

Które rozwiązanie jest bardziej RESTowe? Bo sobie na papierze po raz pierwszy rozpisuję endpointy i się zastanawiam nad tym.

#programowanie #rest #api

[h0lend9r]

@Wrath_of_the_Tyrant: raczej to drugie

[mccloud]

@Wrath_of_the_Tyrant: raczej to pierwsze ;-)
( http://www.restapitutorial.com/lessons/restfulresourcenaming.html )

[ss_wykopek]

@Wrath_of_the_Tyrant: Lepiej to drugie rozwiązanie, chociaż może warto by było być bardziej precyzyjnym i dać /user-items. Z doświadczenia wiem, że płytkie urle lepiej działają. Tu masz dyskusje np. sub zasobów, https://stackoverflow.com/questions/20951419/what-are-best-practices-for-rest-nested-resources odpowiedź z która ja się zgadzam: https://stackoverflow.com/a/36410780

edit: Dodatkowo w pierwszym rozwiązaniu niepotrzebnie wysyłasz {username} gdyż i tak będziesz musiał walidować czy wykonuje ten request poprawna osoba.

[LiczbaPi]

@Wrath_of_the_Tyrant: pierwsze jeśli przedmioty są "wewnątrz" użytkownika np. przedmioty w ekwipunku postaci w grze
drugi jeśli jest to unikatowy podzbiór wszystkich przedmiotów dostępny dla tego użytkownika np: lista promocyjnych ofert produktów generowana na podstawie historii zakupów/ustawień

Ale generalnie dużo zależy od tego jak te dane mają być używane. Np. przekazywanie id usera w tokenie sesyjnym jest problematyczne jeśli do tych samych informacji powinien mieć np. admin - skąd wtedy wziąć informacje

[h0lend9r]

@mccloud: Jezeli uzytkownik moze wyswietlac tylko swoje itemy, to po co "/users/{username}/items"?

[Wrath_of_the_Tyrant]

@h0lend9r: @ss_wykopek: @LiczbaPi:

a jaki jest "state of the art" jeżeli chodzi o wysyłanie razem z requestem danych weryfikacyjnych? Z każdym requestem wysyłać login oraz hasło, czy może zrobić coś w stylu:

/users/key

gdzie user wysyła raz dane logowania i dostaje jakiś tymczasowy N-znakowy hash, który potem przesyła razem z każdym requestem? Wtedy by można te klucze do jakiegoś redisa wepchnąć standardowo i na tym działac.

[ss_wykopek]

@Wrath_of_the_Tyrant: Wele osób stosuje JWT (w tym ja dla kilku projeketów) ale efektywnie przeimplementujesz to co dobre implementacje ciasteczek już oferują, więc jakby zależy od supportu web frameworku którego używaż. A najlepiej to jest nie trzymać haseł u siebie i użyć jakiegoś OAuth providera.

[LiczbaPi]

@Wrath_of_the_Tyrant: Hash (token) np. JWT. Tylko przy JWT pamiętaj, że jak go nie zaszyfrujesz to każdy może go oczytać. Ale jego zaletą, jest to, że możesz w takim tokenie zaszyć np. jakiś JSON i dodać unikalny secret (który będzie np. trzymany w bazie w rekordzie użytkownika) więc możesz bez bawienia się w szyfrowanie wiadomości weryfikować czy token został wygenerowany przez danego użytkownika.

Przykładowo to: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VybmFtZSI6IldyYXRoX29mX3RoZV9UeXJhbnQiLCJyZWFsbmFtZSI6IlBzemVtZWsifQ.5lQybsIZ35TwTm7RCOCrVHs4NwJjVc7gl7EtzaBdcvc
jest token z twoimi danymi, a

[mccloud]

@h0lend9r: IMO backend nie powinień wiedzieć które to są "moje" itemy.
Backend dostaje nazwe usera dla którego itemy ma zwrocić i "klucz" aby sprawdzic czy ma do tego prawo.

Zauważ, że w obu przypadkach @Wrath_of_the_Tyrant chce przekazać nazwe usera - pytanie jest tylko jak.

Jakby backend wiedział które to są "moje" itemy, to wystarczyło by tylko /items - backend wie kim jestem więc klucza i nazwy usera nie muszę podawać.