Problem z zaprojektowaniem ścieżek w API

Odpowiedz Nowy wątek
2019-07-17 09:20
0

Mam aplikację, w której użytkownik może uznać recenzję produktu za pomocną lub niepomocną. Mam tabelę ReviewLike (wiem, słaba nazwa, ma ktoś lepszą?) z kolumnami ReviewId, CustomerId, IsLike. Nie wiem, jak zaprojektować ścieżki w REST API do tego. Wymyśliłem na razie coś takiego:
POST api/review-likes?reviewId=100 {isLike=true}
PUT api/review-likes?reviewId=100 {isLike=false}
DELETE api/review-likes?reviewId=100

1) Czy powinienem dołączyć do tabeli ReviewLike kolumnę z unikalnym id? Z jednej strony jest to niepotrzebne, ale z drugiej strony ścieżki w API ładniej by wyglądały.
2) Czy można to jakoś ładniej rozwiązać? Ten drugi endpoint PUT wydaje mi się dziwny i nienaturalny.

Pozostało 580 znaków

2019-07-17 09:44
2

Jeśli chcesz po czymś identyfikować to użyj to jako pathParameter, jeśli chcesz po czymś filtrować to jako queryParameter. Każda recenzja imo powinna mieć swoje ID i potem jeśli chcesz dostać się do zasobu to:
api/review/{reviewId}
Jeśli chcesz dostać np wszystkie recenzje użytwokownika to
api/user/{userId}/reviews
Jeśli chcesz np wszystkie recenzje usera które są polubieniami to
api/user/{userId}/reviews?isLike=true


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.
edytowany 2x, ostatnio: danek, 2019-07-17 15:09

Pozostało 580 znaków

2019-07-17 09:56

Biorąc pod uwagę, że w tym wypadku aggregate rootem jest review, poszedłbym w coś takiego:

POST /api/reviews/:id/like   # <- dodaje lajka
DELETE /api/reviews/:id/like # <- usuwa lajka

edytowany 2x, ostatnio: Patryk27, 2019-07-17 09:58

Pozostało 580 znaków

2019-07-17 10:01
0

@Patryk27: Tylko czy wtedy nie będę miał RPC? Żeby nie było, takie rozwiązanie mi się podoba, ale ktoś kiedyś pisał, że RPC to zło ;(

Pozostało 580 znaków

2019-07-17 10:03
1

Dlaczego RPC to zło?

Tak czy siak: z jakiegoś powodu aktualnie często propagowane są API, które wyglądają jak lekki wrapper na bazę danych bez żadnych dodatkowych funkcjonalności - podane przeze mnie rozwiązanie jest IMO wysokopoziomowe, czytelne i łatwe w zaimplementowaniu, stąd poszedłbym w tę stronę, nawet jeśli wygląda na rpc-like.


edytowany 2x, ostatnio: Patryk27, 2019-07-17 10:05
Ja nie OP, ale RPC ogólnie jest cienki z tego względu, że próbuje zasymulować, że funkcje zdalne są odpalane lokalnie. IMHO zdecydowanie lepiej działa wymiana wiadomości pomiędzy systemami. - hauleth 2019-07-17 12:02
Model aktorów jest ofc. bardziej naturalny przy pracy z zasobami sieciowymi - jest przy tym również odpowiednio trudniejszy do zaimplementowania w językach, które nie wspierają go natywnie (np. Elixir vs Rust). IMO RPC jest bardziej plug-and-play, co jest sporą przewagą. - Patryk27 2019-07-17 12:20

Pozostało 580 znaków

2019-07-17 10:05
0

Może niekoniecznie zło, ale @Leroy: tu Plus jest taki, ze podejscie restowe jest ustandaryzowane i zrozumiale. Co innego 30 roznych serwisow z podejsciem "RPC over HTTP", bez porzadnej dokumentacji jest pograne, IMO :)

edytowany 1x, ostatnio: nobody01, 2019-07-17 10:07

Pozostało 580 znaków

2019-07-17 10:08
2

Podejście RESTowe miało być ustandaryzowane - ostatecznie wyszła z tego jedna wielka ciapa, którą każdy implementuje w inny sposób (o kodach statusów nie wspominając).

RESTowe API bez dokumentacji jest dokładnie tak samo trudne w przetwarzaniu, jak te wszystkie JSON-RPC itd. i w każdym przypadku bez dokumentacji błądzisz po omacku.


edytowany 1x, ostatnio: Patryk27, 2019-07-17 10:08

Pozostało 580 znaków

2019-07-17 12:32
0

Tak z ciekawości: jak te ścieżki powinny wyglądać w "prawdziwym" REST API?

prawdziwy REST to jak prawdziwe DDD, tyle opinii ilu ludzi ;] - Shalom 2019-07-17 12:38

Pozostało 580 znaków

2019-07-17 12:44
0

Zdefiniuj prawdziwe REST API.


Pozostało 580 znaków

2019-07-17 12:45
0

W tej książce chyba zdefiniowali, ale nie czytałem :( https://helion.pl/ksiazki/res[...]ark-masse,e_2gtc.htm#format/e

Pozostało 580 znaków

2019-07-17 12:46
0

A co jeśli w innej zdefiniowali inaczej?


Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0