practices - POSTS RESTful, ¿PUBLICAS objetos al Uri singular o plural?
restful name conventions (7)
Como POST es una operación de "agregar", podría ser más correcto enviar /products , ya que agregaría un nuevo producto a la lista existente de productos.
Siempre y cuando te hayas estandarizado en algo dentro de tu API, creo que es lo suficientemente bueno.
Dado que las API REST deben ser impulsadas por hipertexto, el URI es relativamente intrascendente 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.
¿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?
/ producto / (singular)
o
/ productos / (plural)
Actualmente utilizamos /products/?query=blah para buscar y /product/{productId}/ para GET PUT y DELETE de un solo producto.
Como muchos dijeron, probablemente puedas elegir cualquier estilo siempre que seas consecuente; sin embargo, me gustaría señalar algunos argumentos en ambos lados; Personalmente estoy predispuesto hacia el singular
A favor de nombres de recursos plurales:
- simplicidad del esquema de URL como usted sabe, el nombre del recurso siempre está en plural
- muchos consideran que esta convención es similar a cómo se abordan las tablas de bases de datos y consideran que esto es una ventaja
- parece ser más ampliamente adoptado
A favor de los nombres de recursos singulares (esto no excluye los plurales cuando se trabaja en múltiples recursos)
- el esquema de URL es más complejo pero obtienes más expresividad
- siempre se sabe cuando se trata de uno o más recursos basados en el nombre del recurso, en lugar de verificar si el recurso tiene un parámetro de ruta de búsqueda de id siguiente
- el plural a veces es más difícil para los hablantes no nativos (cuando no es simplemente una "s")
- la URL es más larga
- la "s" parece ser redundante desde el punto de vista de los programadores
- es incómodo considerar el parámetro ruta como un subconjunto de la colección en lugar de considerarlo como lo que es: simplemente una identificación del recurso que identifica
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 a 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.
Entonces, en tu caso, recomendaría usar /products
Normalmente, utiliza POST para crear un recurso cuando no conoce el identificador del recurso por adelantado, y PUT cuando lo hace. Por lo tanto, debe enviar a / products o PUT a / products / {new-id}.
Con ambos, devolverá 201 Created, y con POST también devolverá un encabezado de ubicación que contiene la URL del recurso recién creado (suponiendo que se haya creado correctamente).
Solo publicaría en el singular /product . Es demasiado fácil mezclar las dos URL y confundirse o cometer errores.
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.
Raramente trabajas formas de nombres en plural. Si tiene una colección (un catálogo de productos), es un catálogo.
podría usar la misma url para todos ellos 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 forma, puede verificar el tipo de solicitud que se envió al servicio web y realizar la acción adecuada según el método de solicitud.