2012-04-24 14 views
6

Estoy construyendo una API REST donde tengo "Libros" y "Usuarios". Solo pueden existir un Libro único. Aunque un Usuario puede tener varios Libros y diferentes usuarios pueden tener el mismo Libro (o referencia al mismo). Un usuario puede agregar información adicional a un libro (por ejemplo, calificación).¿Cómo se maneja cuando los recursos REST están vinculados y amplían los recursos ya existentes?

Mi pregunta es: ¿Cuál es la forma correcta de asignar los recursos cuando los usuarios están "extendiendo" un recurso de libro ya existente con sus propios ajustes?

Ejemplo: un usuario por primera vez no tiene libros pero puede crear un libro. Si el libro no existe, se crea, si existe, obtiene acceso a él. Aunque pueden agregarle su propia información privada adicional.

¿Es esta una manera correcta?

// Todos los Libros con la información básica necesaria se puede llegar a/libros /: id Ejemplo:/libros/1 {

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

}

// Si un usuario crea la libro "The Empire" (serie: 1234) están extendiendo el libro ya existente, pero han agregado información adicional por lo que en realidad es una nueva URL, pero se refiere a la identificación del libro.

ejemplo:/usuarios/421/libros/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." 
} 

O incluso:

{ 
"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." 
} 

O incluso un smth URL como/usuarios/421/libros/1/configuración/

{ 
"rating":5.5, 
"note":"I liked the book but it was too long." 
} 
+1

did @jayraynet responda a su pregunta? –

Respuesta

4

Recomendaría permitir que las "revisiones" se asociaran con múltiples padres (libro, usuario) y luego tener un recurso canónico para la revisión w de la siguiente manera:

libro /books/{book-id}

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

Los comentarios de un libro /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 
} 
]} 

reseñas hechas por un usuario /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 
} 
]} 

recursos canónica para una revisión /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 
} 
]} 

La creación de una nueva revisión puede ser una publicación para el usuario/opiniones, reservar/revisar o revisar recursos con la implementación del servidor de esos ID de usuario predeterminados o Id. De libro, según corresponda.

La implementación del enlace de la url tiene algunas opciones como átomo: enlace.

Además, considere no exponer la identificación sin formato de libros, usuarios y opiniones al cliente/consumidor de estos servicios, y en su lugar exponer la identificación como un URI.

+0

Cuando se trata de autenticación, ¿permitiría que un ** usuario ** publique en cualquiera de estos, pero limite los permisos o solo a/usuario ...? (dado otros tipos autorizados como, autor, editor, etc. que pueden comunicarse principalmente con/books ... –

Cuestiones relacionadas