Diseño de API RESTful: ¿deberían ser opcionales los datos no modificables en una actualización (PUT)?

Question

Estoy en el medio de la implementación de una API RESTful, y no estoy seguro del comportamiento 'aceptado por la comunidad' para la presencia de datos que no pueden cambiar. Por ejemplo, en mi API hay un recurso 'archivo' que cuando se crea contiene una cantidad de campos que no se pueden modificar después de la creación, como los datos binarios del archivo y algunos metadatos asociados. Además, el 'archivo' puede tener una descripción escrita y etiquetas asociadas.

Mi pregunta se refiere a hacer una actualización de uno de estos recursos de 'archivo'. Un GET de un 'archivo' específico devolverá todos los metadatos, las etiquetas de descripción & asociadas con el archivo, más los datos binarios del archivo. ¿Debería un PUT de un recurso 'archivo' específico incluir los campos 'solo lectura'? Me doy cuenta de que puede codificarse de cualquier manera: a) incluir los campos de solo lectura en los datos PUT y luego verificar que coincidan con el original (o emitir un error) ob) ignorar la presencia de los campos de solo lectura en los datos PUT porque no pueden cambiar, nunca emiten un error si no coinciden o faltan porque la lógica los ignora.

Parece que podría ir de cualquier manera y ser aceptable. El segundo método para ignorar los campos de solo lectura puede ser más compacto, porque el cliente API puede omitir el envío de datos de solo lectura si así lo desean; lo que parece bueno para las personas que saben lo que están haciendo ...

Answer 1

Personalmente, ambas formas son aceptables ... sin embargo, si fuera usted, optaría por la opción A (consulte los campos de solo lectura para asegurarse no se cambian, sino arrojan un error). Dependiendo del alcance de su proyecto, no puede suponer lo que los consumidores saben acerca de su Restful WS en profundidad porque la mayoría de ellos no leen documentaciones o WADL, incluso si son los experimentados. :)

Si no proporciona comentarios inmediatos a los consumidores de que ciertos campos son de solo lectura, tendrán una falsa suposición de que su servicio web se encargará de todos los cambios que hayan realizado sin doble comprobación, O una vez que descubren las actualizaciones "inconsistentes", se quejan a otros de que su servicio web tiene errores.

Usted puede acercarse a esto de dos maneras diferentes si el campo de sólo lectura no coincide con los valores originales ...

1. No procesar la solicitud. Envíe un código de conflicto 409 y un mensaje de error específico.
2. Procese la solicitud, envíe un mensaje 200 OK y un mensaje que indique que los cambios realizados son ignorados por los campos de solo lectura.

Answer 2

A menos que los datos de solo lectura constituyan una parte importante de los datos (hasta el extremo de que la transmisión de los datos de solo lectura tiene un impacto notable en el tráfico de red y tiempos de respuesta), debe escribir el servicio para aceptar los campos de solo lectura en el PUT y verificarlos para ver si hay cambios. Simplemente es más fácil tener la misma información entrando y saliendo.

Mírelo de esta manera: puede hacer que los campos de solo lectura sean opcionales en el PUT, pero aún tendrá que/debería escribir el código en el servicio para verificar que los campos de solo lectura que se recibieron contengan Valores esperados. Tienes que escribir la verificación de solo lectura de cualquier manera.

Prohibir los campos de solo lectura en el PUT es una mala idea porque requerirá que los clientes eliminen los campos que recibieron de usted en el GET. Esto requiere que el cliente se involucre más íntimamente con sus datos y semántica de lo que realmente necesita ser. Los clientes considerarán que esto es un dolor de cabeza, una complicación innecesaria, y francamente tuyo para aumentar su carga.Tomar los datos recibidos de su GET, modificar un campo de interés y enviársela de nuevo con un PUT debería ser un simple viaje de ida y vuelta para el cliente. No compliques las cosas cuando no tienes que hacerlo.