2010-12-23 7 views
11

Digamos que tenemos una entidad que contiene una lista de usuarios en el servidor, y queremos exponer esto como descanso. ¿Cuál es la forma correcta de hacerlo?¿Cuál es la forma correcta de tratar agregar/eliminar relaciones de muchos a muchos en REST?

Mi primera suposición es algo como esto:

/entity/1/user/5 

Podemos utilizar PUT y DELETE para las actualizaciones de eliminaciones?

¿Es esto así? Fui a wikipedia donde habla sobre el descanso, y su punto de vista es que todo tiene solo 1 nivel de profundidad. ¿Entonces quizás quieran que utilices PUT/POST y entregues todo el gráfico JSON y actualices todo al mismo tiempo?

+0

¿qué quieres decir con entitiy, este es el resto api >> https://graph.facebook.com/19292868552 – XMen

+0

@Rahul Mehta: entidad como en un objeto comercial, como "hotel", "club", "pregunta", etc. – egervari

+0

podría intentar algo como OData http://www.odata.org/developers/protocols/json-format#RepresentingCollectionsOfEntries – jfs

Respuesta

10

Su ejemplo es un enfoque perfectamente válido. Sin embargo, en muchos casos, un User puede existir fuera del contexto de solo entity. Tiendo a identificar los recursos de forma aislada, por ejemplo:

/entity/1 
/user/5 

Para ver los usuarios asociados a una entidad que yo usaría:

/entity/1/users 

Adición de un usuario que se podría hacer mediante la publicación de un usuario,

POST /entity/1/users 
<User> 
... 
</User> 

Eliminación de un usuario sería

DELETE /User/5 

Actualización o la creación de un usuario se podría hacer con PUT

Extracción de la asociación entre un usuario y una entidad requiere un poco de creatividad. Usted podría hacer

DELETE /Entity/1/User/5 

como usted sugiere, o algo así

DELETE /Entity/1/UserLink?UserId=5 

o simplemente

DELETE /Entity/1/Users?UserId=5 

Es la realidad no es muy importante para el usuario de la API de lo que su URI parece .Es bueno ser consecuente con tu cordura, es bueno elegir esquemas que sean fáciles de enviar con tu marco de trabajo de servidor, pero no es lo que parecen tus URI, es lo que haces con ellos lo que es importante.

+0

Gracias por todos los enfoques. Creo que su publicación es muy útil porque confirma que lo que estoy haciendo es correcto entonces. Por ejemplo, tengo/entity/1 y/user/5 para cuando los uso individualmente ... Solo estaba teniendo problemas con el caso de colección de muchos a muchos. Como dijiste, para las eliminaciones, estás más o menos obligado a hacer algo como/entity/1/user/5. Como sé cuál es la identificación por adelantado ... no es mucho más fácil hacer una publicación en realidad y puedo mantener mis URL de agregar/eliminar de la misma manera, lo que creo que aumenta la cordura;) Gracias por la respuesta. – egervari

1

Utilizo su método para entidades padre/hijo, pero para muchas-a-muchas uso una matriz en mi objeto JSON que representa esa entidad.

Así, utilizando el ejemplo:

GET /entity/1 

podría devolver un objeto de entidad algo como esto:

{"entityID":1,"name":"whatever","users":[1,2,3,4,5]} 

PUT pasaría en este mismo objeto, y actualizar tanto la entidad y los usuarios. A continuación, para obtener la información específica de usuario:

GET /users/3 

Uso de poner en usuarios/3 actualizaría el usuario. PUT on/entity/1 conectaría a los usuarios con entidades. Desafortunadamente, no hay mucha información buena sobre cómo modelar este tipo de cosas.

+0

Hrm ... bueno, yo ya tengo/entity/x y/user/x para las entidades individuales. ¿No sería su método un poco ineficiente? Si quiero agregar un nuevo usuario a una entidad, tendría que obtener la lista actual de usuarios, anexar uno y luego devolver toda la lista. Esa es realmente la forma estándar de hacerlo? Suena extraño ... pero creo que no lo pondría al margen de las personas que escriben estos estándares;) – egervari

+0

No, no es un estándar, simplemente algo que se me ocurrió. Las tablas de resolución son tan simples y estrechas que siempre acabo de borrar y recrear los registros cada vez que se modificó la entidad padre. La simplicidad prevalece sobre la ineficiencia en mi opinión. El único caso en que no haría esto es si la misma entidad iba a ser editada con la frecuencia suficiente como para ser relevante. –

Cuestiones relacionadas