REST API - jakie endpointy?

REST API - jakie endpointy?
IN
  • Rejestracja:prawie 10 lat
  • Ostatnio:ponad 4 lata
  • Postów:4
0

Cześć,

ostatnio próbuję napisać proste REST API. Poczytałem co nieco o dobrych praktykach i znalazłem, że dobrze jest dostarczać "zagnieżdżone" endpointy (swoją drogą nie wiem jakiej nomenklatury używać do tego, co chcę opisać). Ale do rzeczy.

Przykładowo : mam relację ManyToMany pomiędzy encją Team i Member - każdy Team ma wiele Memberów, a każdy Member należy do wielu Teamów. I oczywiste wydają się takie endpointy (na razie skupiam się na GET):

GET /teams
GET /members
GET /teams/{id}
GET /members/{id}

Idąc dalej tym tokiem wydaje się sensowne, aby zapewnić również:

GET /teams/{id}/members
GET /members/{id}/teams

I jeszcze dalej...

GET /teams/{id}/members/{id}
GET /members/{id}/teams/{id}
GET /teams/{id}/members/{id}/teams
GET /members/{id}/teams/{id}/members

I tak w koło Macieju...

Stąd moje pytanie - czy taki właśnie jest zamysł REST API czy czegoś nie do końca rozumiem? Jeśli tak, to czy istnieje jakiś sprytny trik (jakieś redirecty?) na zrealizowanie czegoś takiego? Piszę to w Spring Boocie ze Spring Data.

I na koniec taka moja obserwacja - szokujące, ile jest tutoriali uczących złych praktyk i łamiących wszystkie zasady RESTa :D

S9
  • Rejestracja:ponad 10 lat
  • Ostatnio:6 miesięcy
  • Lokalizacja:Warszawa
  • Postów:3573
2

Według mnie GETna takie endpointy jak:
/teams/{team_id}/memember/{memember_id} raczej sensu nie mają.
Informacje o zespole uzyskujesz uderzajac pod endpoint /teams/{team_id} zaś o członku memember/{memember_id}
/teams/{team_id}/memembers/{memember_id} mogłoby być dobre bardziej pod DELETE, ew. PUT w celu edycji powiązania (usuniecie członka z zespołu np.)


"w haśle <młody dynamiczny zespół> nie chodzi o to ile masz lat tylko jak często zmienia się skład"
axde
  • Rejestracja:prawie 6 lat
  • Ostatnio:około 5 lat
2
invisus napisał(a):

(...)
I na koniec taka moja obserwacja - szokujące, ile jest tutoriali uczących złych praktyk i łamiących wszystkie zasady RESTa :D

Takie rzeczy w Java to standard. Jest 1000 artykułów na ten sam temat, a 998 z nich jest przepisanych jeden do jednego z innego z tymi samymi błędami.
Łap fajny treściwy i krótki tutorial:

Shalom
  • Rejestracja:około 21 lat
  • Ostatnio:około 3 lata
  • Lokalizacja:Space: the final frontier
  • Postów:26433
4

Wystawiaj endpointy które mają jakiś biznesowy sens. Jak chcesz zdumpować restem całą bazę danych to weź sobie Spring Data Rest i w ogóle nie pisz zadnego kodu. Sens niewielki, no ale jak ktoś lubi to kto mu zabroni?


"Nie brookliński most, ale przemienić w jasny, nowy dzień najsmutniejszą noc - to jest dopiero coś!"
IN
  • Rejestracja:prawie 10 lat
  • Ostatnio:ponad 4 lata
  • Postów:4
0

Dzięki Panowie, o to chodziło :) To, że takie chainowanie endpointów nie jest szczególnie wartościowe to się domyślałem i nie jest moim celem. Bardziej zastanawiałem się, czy nie robi się czegoś takiego jakimś automagicznym sposobem.

Charles_Ray
  • Rejestracja:około 17 lat
  • Ostatnio:około 4 godziny
  • Postów:1875
1

Tak jak @Shalom napisał, nie do tego to służy. Rest jest stylem architektonicznym, a nie ładnymi urlami.


”Engineering is easy. People are hard.” Bill Coughran

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.