¿Es razonable que los recursos REST sean singulares y plurales?

10

Me he estado preguntando si, en lugar de un diseño más tradicional como este:

api/Products
GET // gets product(s) by id
PUT // updates product(s) by id
DELETE // deletes (product(s) by id
POST // creates product(s)

¿Sería más útil tener un singular y un plural, por ejemplo:

api/Product
GET // gets a product by id
PUT // updates a product by id
DELETE // deletes a product by id
POST // creates a product

api/Products
GET // gets a collection of products by id
PUT // updates a collection of products by id
DELETE // deletes a collection of products (not the products themselves)
POST // creates a collection of products based on filter parameters passed

Entonces, para crear una colección de productos que podría hacer:

POST api/Products {data: filters} // returns api/Products/<id>

Y luego, para referenciarlo, puede hacer:

GET api/Products/<id> // returns array of products

En mi opinión, la principal ventaja de hacer las cosas de esta manera es que permite el almacenamiento en caché fácil de colecciones de productos. Uno podría, por ejemplo, poner una vida útil de una hora en colecciones de productos, reduciendo drásticamente las llamadas en un servidor. Por supuesto, actualmente solo veo el lado bueno de hacer las cosas de esta manera, ¿cuál es el inconveniente?

rest Eva
fuente

Respuestas:

6

A menudo, cuando una colección va a ser la forma más útil de interactuar con su API, puede ser más simple pensar en una sola como una colección con un solo miembro. Luego, si más tarde desea exponer una API para interactuar con solteros, simplemente necesita convertir el sencillo pasado en una colección con ese miembro y luego usa la implementación idéntica de la otra API.

Supongo que lo que digo aquí es que, si desea que las colecciones sean un mecanismo de interacción, comience con la API solo de colección y, una vez que el sistema esté completo, la otra API es un accesorio auxiliar simple en la capa de interfaz que puede agregar, si Lo encuentras particularmente útil. Sin embargo, es posible que su utilidad sea lo suficientemente mínima como para aplicar YAGNI y solo use la interfaz de colecciones para las pocas instancias de solteros que desee.

Jimmy Hoffa
fuente
Si bien estoy de acuerdo con su opinión, suponiendo que usemos el ejemplo anterior, dado que la API / Productos POST se usaría para pasar los parámetros del filtro de recolección y no los datos para la creación de nuevos productos, ¿cuál sería una forma razonable de crear un nuevo producto? sin API / producto?
Eva
@Evan ¿Por qué no se puede publicar en la API / Productos insertar múltiples (o una colección de uno) Productos? Eso me parece lo más lógico. Quizás publique Productos / Filtro para crear filtros, u obtenga si son una tarea de recuperación y no de creación.
Jimmy Hoffa
Gracias por la elaboración, Jimmy. La razón por la que no lo vi así fue porque estaba considerando, en el ejemplo anterior, la colección como un recurso identificado en sí mismo. En un servidor, api / Product podría ser "Product" y api / Products, por lo tanto, "ProductCollection". Sin embargo, después de considerarlo, creo que podría ser mejor abstraerlo de la API, como en su sugerencia ... ahora a la pregunta real, ¿se alejó de esa parada de camiones en su camino a Tailandia, o se fue? en el maletero de un auto?
Eva
@Evan, te daré dos pistas: gaviotas.
Jimmy Hoffa
1

La desventaja es que el programa de llamada también tiene que pluralizar el nombre del recurso, lo que puede ser complicado para los idiomas de los clientes que no tienen mecanismos de pluralización integrados. Si lo deja en singular, es más fácil para la persona que llama automatizar la generación de código para su biblioteca cliente.

Si desea mitigar esto, puede generar los SDK para su servicio REST usted mismo. O bien, puede ser obstinado y lidiar con las quejas :)

Chris McCall
fuente