Jak radzić sobie, gdy zasoby REST są połączone i rozszerzają istniejące zasoby?

Question

Buduję API REST, gdzie mam "Książki" i "Użytkownicy". Ich może istnieć tylko jedna wyjątkowa Księga. Chociaż użytkownik może mieć kilka książek, a różni użytkownicy mogą mieć tę samą książkę (lub odwoływać się do tego samego). Użytkownik może dodawać dodatkowe informacje do książki (np. Ocena).

Moje pytanie brzmi: Jaki jest właściwy sposób mapowania zasobów, gdy Użytkownicy "rozszerzają" istniejący zasób Książek z własnymi ustawieniami?

Przykład: Użytkownik po raz pierwszy nie ma książek, ale może utworzyć książkę. Jeśli książka nie istnieje, zostanie utworzona, jeśli istnieje, otrzyma do niej dostęp. Chociaż mogą dodawać do niego własne prywatne dodatkowe informacje.

Czy to właściwy sposób?

// Wszystkie Książki z podstawowego wymaganych informacji można dotrzeć/książki /: id Przykład:/książki/1 {

"id":1, 
"title":"The Empire", 
"description":"Description about the book", 
"serial":1234 

}

// Jeśli użytkownik tworzy książka "The Empire" (serial: 1234) poszerza już istniejącą książkę, ale dodała dodatkowe informacje, więc jest to nowy adres URL, ale odnosi się do identyfikatora Book.

Przykład:/users/421/książki/1/

{ 
"id":1, 
"title":"The Empire", 
"description":"Description about the book", 
"serial":1234, 
"rating":5.5, 
    "note":"I liked the book but it was too long." 
} 

lub nawet:

{ 
"book":{ 
    id":1, 
    "title":"The Empire", 
    "description":"Description about the book", 
    "serial":1234, 
    } 
"rating":5.5, 
"note":"I liked the book but it was too long." 
} 

a nawet czymś URL podobny/users/421/książek/1/ustawienia/

Answer 1

Polecam zezwolenie na powiązanie "recenzji" z wieloma rodzicami (książka, użytkownik), a następnie posiadanie kanonicznego zasobu dla rewizji w sposób następujący:

Book /books/{book-id}

{ 
"id":1, 
"title":"The Empire", 
"description":"Description about the book", 
"serial":1234 
} 

Recenzje książki /books/{book-id}/reviews

{[ 
{ 
"id":1, 
"userId":user1, 
"bookId":1, 
"rating":5.5, 
"note":"I liked the book but it was too long.", 
"url":http://server/reviews/1 
}, 
{ 
"id":2, 
"userId":user2, 
"bookId":1, 
"rating":1, 
"note":"boo, i didn't like it!", 
"url":http://server/reviews/2 
} 
]} 

Recenzje przez użytkownika /users/{user-id}/reviews

{[ 
{ 
"id":1, 
"userId":user1, 
"bookId":1, 
"rating":5.5, 
"note":"I liked the book but it was too long.", 
"url":http://server/reviews/1 
}, 
{ 
"id":2, 
"userId":user2, 
"bookId":1, 
"rating":1, 
"note":"boo, i didn't like it!", 
"url":http://server/reviews/2 
}, 
{ 
"id":5, 
"userId":user1, 
"bookId":3, 
"rating":2, 
"note":"I like to read", 
"url":http://server/reviews/5 
} 
]} 

Canonical zasobów o przegląd /reviews/{review-id}

{[ 
{ 
"id":1, 
"userId":user1, 
"bookId":1, 
"rating":5.5, 
"note":"I liked the book but it was too long.", 
"url":http://server/reviews/1 
}, 
{ 
"id":5, 
"userId":user1, 
"bookId":3, 
"rating":2, 
"note":"I like to read", 
"url":http://server/reviews/5 
} 
]} 

Tworzenie nowej recenzji może być postem dla użytkownika/recenzji, książki/recenzji lub oceną zasobów za pomocą serwera, w zależności od potrzeby, za pomocą tych usług POST, które domyślnie używają identyfikatora użytkownika lub książki.

Implementacja łącza URL ma kilka opcji, takich jak atom: link.

Należy również wziąć pod uwagę, że nie należy ujawniać surowego identyfikatora książek, użytkowników i opinii klientowi/konsumentowi tych usług, a zamiast tego ujawniać identyfikator jako identyfikator URI.