Jak należy obsługiwać Hateoas z poziomu interfejsu?

Question

Mam to pytanie, które przez chwilę krążyło w mojej głowie. Załóżmy, że skonstruowaliśmy nasz projekt z backendem i frontendem na osobnych warstwach. Tak więc, od frontend, chcemy uzyskać Schultz, który pochodzi od formatu hal+json:

GET /customers/1 HTTP/1.1 
Accept: application/hal+json 
{ 
    "name": "Alice", 
    "links": [ { 
     "rel": "self", 
     "href": "http://localhost:8080/customer/1" 
    } { 
     "rel": "transactions", 
     "href": "http://localhost:8080/customer/1/transactions" 
    }] 
} 

Następnie z frontend chcę, aby wszystkie transakcje z klientami. Moje pytanie brzmi: jak mam zdobyć adres URL? czy powinien pochodzić z reakcji? czy powinienem zbudować go wewnętrznie?

Jeśli pójdziemy z pierwszą opcją, myślę, że być może nie byłoby elegancko do iterowania wszystkich linków, dopóki nie otrzymamy tego, którego chcemy. Ponadto może zdarzyć się sytuacja, w której nie będziemy mieć łącza do żądania, które chcemy wykonać.

jeśli pójdziemy z drugą opcją, nie rozumiem, jak zbudować ten adres URL, jeśli nie mamy prawdziwych identyfikatorów. Jak mogę utworzyć nowe transakcje dla klientów, jeśli hateoas zastąpi identyfikatory ids odnośnikami i nie mam już odniesienia do obiektu w ciele?

Pomyślałem, że być może serwis powinien obsługiwać zarówno application/hal+json (zorientowany na użytkowników), jak i application/json (zorientowany na klientów), ale nie widzę, że tak to właśnie robi.

Co myślisz?

Answer 1

Zdecydowanie pierwsza opcja. Mianowicie, ponieważ hateoas jest końcowym etapem Richardson Maturity Model oczekuje się, że klienci przestrzegać dostarczonych łączy, a nie do budowania adresów URL przez siebie:

Punktem kontroli hipermedialnymi jest to, że oni mówią nam, co możemy zrobić obok i URI zasobu, który musimy manipulować, aby to zrobić. Zamiast tego, że musimy wiedzieć, gdzie opublikować naszą prośbę o powołanie, kontrola hipermedia w odpowiedzi mówi nam, jak to zrobić.

Jakie są korzyści z tego płynące? Mogę myśleć o co najmniej dwóch:

• Prosta modernizacja REST API - deweloperzy po stronie serwera można zmienić URI z zasobów, bez łamania kodu po stronie klienta, ponieważ klienci po prostu wykonaj podane linki; dodatkowo programiści po stronie serwera mogą z łatwością dodawać nowe łącza.
• Odporność - po zastosowaniu linków kod po stronie klienta nigdy nie będzie próbował uzyskać dostępu do niedziałających linków, błędnych linków itp.

Q: Ponadto, nie może zdarzyć się sytuacja, w której nie mamy link do wniosku chcemy zrobić?

Do projektanta interfejsu API należy zapewnienie wszystkich wymaganych łączy. Front-end developer nie powinien się tym przejmować.

Zobacz także:

• Rest lesson learned - avoid hackable URLs

Answer 2

HATEOAS (Hypermedia jako silnik stanu aplikacji) jest ograniczeniem architektury aplikacji REST. Można spojrzeć na dokumentacji Wiosna hateoas na przykład:

https://spring.io/understanding/HATEOAS

inny link o tym przy użyciu Spring i angularjs jest dostępny tutaj:

AngularJS and Spring HATEOAS tutorial

Ten jeden wydaje się być na tyle dobra i obsługuje twój przypadek użycia.

Pozdrawiam, André