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-18 12:44
0

Onaniści "jedynego słusznego podejścia" znajdą się wszędzie, ale to nie oznacza, że ich "jedyne słuszne podejście" jest jedyne albo słuszne.

Pozostało 580 znaków

2019-07-18 13:04
0

Ale każda z frakcji twierdzi, że tylko ich rest jest restowy. Dlatego napisałem, że nie da się dobrze restowo zalogować, bo zawsze ktoś "udowodni", że to nie jest rest. :P


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-07-25 20:27
1

Przede wszystkim nie pakowałbym domeny na siłę do ścieżki API. Skomplikowana domena i REST API to powinny być dwie dość osobne warstwy. Co innego CRUD... albo "Encja na twarz i pchasz".
Możesz zrobić np:

POST /reviews/{id}/upvote
POST /reviews/{id}/downvote

gdzie ciałem będzie wiadomość... choćby pusta. Bardzo.. emm... zasobowa reprezentacja domeny.


Pozostało 580 znaków

2019-07-25 21:08
0

@AreQrm: co nazywasz "pustą wiadomością" w kontekście HTTP POST?


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-07-25 21:35
0

Odnośnie

AreQrm napisał(a):

Przede wszystkim nie pakowałbym domeny na siłę do ścieżki API. Skomplikowana domena i REST API to powinny być dwie dość osobne warstwy. Co innego CRUD... albo "Encja na twarz i pchasz".
Możesz zrobić np:

POST /reviews/{id}/upvote
POST /reviews/{id}/downvote

gdzie ciałem będzie wiadomość... choćby pusta. Bardzo.. emm... zasobowa reprezentacja domeny.

oraz

Patryk27 napisał(a):

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

mam pytanie. Dlaczego POST? (nie twierdzę, że powinno być PUT)

  • POST tworzy nowy zasób, a tutaj nie tworzymy nowego
  • POST nie jest "idempotent" - w tym przypadku ok
  • PUT aktualizuje zasób, ale powinien zostać wysłany w całości
  • PUT jest "idempotent" - w tym przypadku nie pasuje

Co, gdy mamy wykonywać czynności, które nie podpadają pod "tworzeniu zasobu" lub "aktualizację zasobu" (np. zatrzymać lub zrestartować aplikację)? W API Dockera zarządzanie kontenerami jest zrobione podobnie jak w zacytowanych postach, czyli: POST /containers/123/{start, stop, pause, kill, restart}.

To wynika z konwencji, jakiejś specyfikacji, czegoś innego?

Poza tym jest jeszcze PATCH, ale raczej mało popularny?

Pozostało 580 znaków

2019-07-25 21:49
1

@Potat0x:
protokół http nie został w ogóle zaprojektowany do takich operacji, więc trudno mówić która jest właściwa. Nie mniej powstał nieformalny protokół, który mówi, że jak wykonujesz jakąś operacje to robisz to POST, jak coś pobierasz to GET.


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.

Pozostało 580 znaków

2019-07-25 22:08
1

POST tworzy nowy zasób, a tutaj nie tworzymy nowego

Ja powiedziałbym, że tutaj tworzymy nowy zasób o nazwie np. ReviewLike :-)


W sumie to prawda (dodajemy kolumny do tabeli) :) - Potat0x 2019-07-26 11:53

Pozostało 580 znaków

2019-07-26 01:37
2
Potat0x napisał(a):

mam pytanie. Dlaczego POST? (nie twierdzę, że powinno być PUT)

  • POST tworzy nowy zasób, a tutaj nie tworzymy nowego
  • POST nie jest "idempotent" - w tym przypadku ok
  • PUT aktualizuje zasób, ale powinien zostać wysłany w całości
  • PUT jest "idempotent" - w tym przypadku nie pasuje

Generalnie POST się używa zawsze, gdy nic innego nie pasuje. :)
A co do PUT, to może też tworzyć zasoby, jeśli nie istnieją Nie wiem czy to nie pasuje tu bardziej. Ale nie wiem też, czy PUT w ogóle jest RESTful. :P

Poza tym jest jeszcze PATCH, ale raczej mało popularny?

No bo to piąte słowo, a CRUD ma cztery. ;)

PS. Czemu piszesz idempotentny po angielsku i w cudzysłowie?


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
Nie chciałem pisać czegoś w rodzaju "randomowy"/"customowy", ale teraz sprawdziłem i okazuje się, że w polskim jest takie słowo :P - Potat0x 2019-07-26 11:48
Jest od dawna, przecież to nie jest związane z restem. :P - somekind 2019-07-26 12:16

Pozostało 580 znaków

2019-07-26 14:47
0

@Potat0x: Bo dodajesz nowy Upvote/Like.
@somekind: chodziło mi raczej o brak ciała w ogóle. Źle to napisałem.


POST bez body wygląda moim zdaniem dość dziwnie. - somekind 2019-07-26 14:59
Zgadzam się, to nie jest typowe. Nie jest też jednak z punktu widzenia HTTP złe. Zawsze też można coś nawet "na siłę" wsadzić. Jakieś ID użytkownika, czy coś innego pożytecznego w danym kontekście. W zasadzie nie pamiętam sytuacji, gdzie bym sam tak zrobił... - AreQrm 2019-07-26 15:02

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