¿Cuál de estos URI sería más adecuado para recibir POST (agregar producto (s))? ¿Hay mejores prácticas disponibles o solo son preferencias personales?POSTES RESTful, ¿PUBLICAS objetos al Uri singular o plural?
/producto/ (singular)
o
/productos/ (plural)
Actualmente usamos /products/?query=blah para la búsqueda y /product/{productId}/ para GET PUT & elimina de un solo producto .
Desde POST es una operación de "añadir", que podría ser más Englishy para su anuncio /products, ya que estaría introducción de un nuevo producto a la lista existente de productos.
Mientras se haya estandarizado en algo dentro de su API, creo que es suficiente.
Dado que las API REST deberían estar basadas en hipertexto, el URI es relativamente inconsecuente de todos modos. Los clientes deberían extraer los URI de los documentos devueltos y usarlos en solicitudes posteriores; por lo general, las aplicaciones y las personas no necesitarán adivinar ni interpretar visualmente los URI, ya que la aplicación les indicará explícitamente a los clientes qué recursos y URI están disponibles.
Iría más lejos y diría que usar la forma plural es definitivamente más natural que el singular. –
Si está intentando crear un slug URL legible, el singular a veces puede sonar más natural (para lectores humanos), p. "/ producto/15", leído directamente es "Producto 15", para que sepa que está tratando con un único producto único.Pero luego se queda con qué hacer con la "lista de todos los productos", poniéndolo en/product (que suena raro para una lista) o/products (tiene que admitir dos URI para el mismo tipo de recurso en su código) Pero, en cualquier caso, las babosas URI legibles no suelen ser el objetivo de una aplicación RESTfully diseñada, ya que generalmente no es para consumo humano. –
Releyendo mi comentario Me di cuenta de que mi intención no era muy clara. Prefiero usar el plural para usar un POST para anexar, pero un non-plural para GET y PUT si el recurso es una sola entidad. Como ya dije en el pasado, nombrar REST uris es tan importante como nombrar las clases y métodos en el diseño de OO. es decir, no es esencial usar buenos nombres, pero realmente ayuda. –
Usted PUBLICA o RECIBE una sola cosa: un solo PRODUCTO.
A veces OBTIENE sin un producto específico (o con criterios de consulta). Pero aún lo dices en singular.
Rara vez trabajas formas de nombres en plural. Si tiene una colección (un catálogo de productos), es un catálogo.
La mayoría de las recomendaciones que he visto para API RESTful dicen lo contrario. Suele tener más sentido tener/products y/products/{id} ya que la raíz es la colección (plural) y la que tiene un identificador es un elemento en esa colección (selección de plural == singular). Los productos pueden considerarse un catálogo, pero ¿qué ocurre si se trata de películas o comentarios? –
Aunque es cierto, incluso StackOverflow usa las colecciones plurales en sus URL, no estoy de acuerdo. Singular tiene más sentido porque un URI identifica un recurso (singular), particularmente para POST. –
Un URI identifica un recurso. A veces, un recurso es una lista de cosas. No veo ninguna razón para limitarse a nombres singulares. –
Normalmente, utiliza POST para crear un recurso cuando no conoce el identificador del recurso de antemano, y PUT cuando lo hace. Por lo tanto, debe enviar a/products o PUT a/products/{new-id}.
Con ambos, devolverá 201 Creado, y con el POST adicionalmente devolverá un encabezado de Ubicación que contiene la URL del recurso recién creado (suponiendo que se haya creado correctamente).
Más uno para mencionar el encabezado 'Ubicación', que a menudo se olvida. –
puede usar la misma url para todas ellas y usar MessageContext para determinar qué tipo de acción deseaba realizar la persona que llamaba del servicio web. No se especificó ningún idioma pero en Java puede hacer algo como esto.
WebServiceContext ws_ctx;
MessageContext ctx = ws_ctx.getMessageContext();
String action = (String)ctx.get(MessageContext.HTTP_REQUEST_METHOD);
if(action.equals("GET")
// do something
else if(action.equals("POST")
// do something
De esta manera se puede comprobar el tipo de solicitud que se envía al servicio web y realizar la acción apropiada basada en el método de la petición.
¿Pero qué URI debe usar, el singular o el plural? –
Cualquiera que él quiera funcionaría. Tengo varios servicios de descanso que realizan diferentes operaciones basadas según el método de solicitud. Podría usar el plural o el singular ya que la operación que se llevará a cabo dependerá solo de la solicitud. método de la uest Entonces/product? Query = blah could podría manejar la misma solicitud que/products? Query = blah haciendo uso del método de solicitud. Espero que tenga sentido que haya sido un día largo y mi cerebro esté cansado. – ChadNC
No responde la pregunta: singular versus plural. Muchos frameworks ya soportan el enrutamiento basado en métodos de solicitud HTTP (sin tener que codificar manualmente). –
Solo publicaría en el singular /product. Es demasiado fácil mezclar las dos URL y confundirse o cometer errores.
Aaack. Publicar en plural, no en singular. Plural da un índice que tiene sentido, singular no. – MikeSchinkel
En el diseño RESTful, existen algunos patrones para crear nuevos recursos. El patrón que elija depende en gran medida de quién es responsable de elegir la URL para el recurso recién creado.
Si el cliente es responsable de elegir la URL, entonces el cliente debe PONER en la URL del recurso.Por el contrario, si el servidor es responsable de la URL del recurso, entonces el cliente debe enviar a un recurso "de fábrica". Normalmente, el recurso de fábrica es el recurso principal del recurso que se está creando y, por lo general, es una colección que está pluralizada.
Así, en su caso, yo recomendaría el uso de /products
Como muchos dijeron, es probable que pueda elegir cualquier estilo que desee, siempre y cuando sean compatibles, sin embargo, me gustaría señalar algunos argumentos en ambos lados ; Yo personalmente estoy sesgado hacia singular
En favor de los nombres de recursos plural:
En favor de los nombres de recursos singulares (esto no excluye plurales cuando se trabaja en múltiples recursos)
* "es incómodo considerar el parámetro de ruta como un sub-recurso de la colección" * ¿Por qué? Si se modela correctamente, la URL expresa la jerarquía correctamente. Personalmente creo que * puede * volverse * incómodo si * el mismo * recurso está disponible en varios lugares de esta manera. Pero mientras haya un solo recurso "propietario", tiene perfecto sentido, pienso. '/ books/of-men-and-mice/chapters/1', or' orders/12543/orderlines/2', o 'places/EU/nl/Amsterdam', etc. Debería evitar mapear todas las relaciones de esta forma, simplemente 'poseer' relaciones (donde se establece EN ELIMINAR CASCADA en el DB por lo general). –
No soy ajeno a usar el formulario plural, pero ejemplos como "/ orders/1234" no me parecen consistentes: orders es plural, mientras que 1234 es un id único y, por lo tanto, representa un objeto singular. En mi opinión, todos los pedidos y el orden identificados por id 1234 representan un solo recurso (conjunto). No dos. Podría argumentar que el único recurso es un subconjunto del todo y puedo aceptarlo, pero eso es una jerarquía artificial. – arpadf
Bueno, mi punto final de colección simplemente devuelve una matriz. Si yo quisiera definir una matriz, también se nombraría en forma plural. P.ej.'var books = [{title: 'Of men and Mice'}, {..}, {..}]'. Entonces se siente muy consistente conmigo. –
me hace pensar en colecciones de programación - artículo [4] o artículos [4]. –
Lo RESTful que se debe hacer es usar * el mismo prefijo para colecciones y elementos individuales. Para que pueda POSTAR o PONER en el mismo punto final desde el que puede OBTENER. Si genera la ID en el servidor, la convención es POSTAR a la colección. Si la ID se genera en el cliente, la convención es POST a '/ endpoint/{new_id}'. –