Potencia idem
Siguiendo el RFC, un PUT tendría que entregar el objeto completo al recurso. La razón principal de esto, es que PUT debe ser idempotente. Esto significa que una solicitud, que se repite, debe evaluar el mismo resultado en el servidor.
Si permites actualizaciones parciales, ya no puede ser idem-potente. Si tienes dos clientes. Cliente A y B, entonces el siguiente escenario puede evolucionar:
El cliente A obtiene una imagen de las imágenes de recursos. Esto contiene una descripción de la imagen, que sigue siendo válida. El cliente B pone una nueva imagen y actualiza la descripción en consecuencia. La imagen ha cambiado. El cliente A ve, no tiene que cambiar la descripción, porque es lo que desea y solo pone la imagen.
Esto llevará a una inconsistencia, ¡la imagen tiene los metadatos incorrectos adjuntos!
Aún más molesto es que cualquier intermediario puede repetir la solicitud. En caso de que decida de alguna manera el PUT falló.
El significado de PUT no se puede cambiar (aunque puedes usarlo mal).
Otras opciones
Afortunadamente hay otra opción, esta es PATCH. PATCH es un método que le permite actualizar parcialmente una estructura. Simplemente puede enviar una estructura parcial. Para aplicaciones simples, esto está bien. No se garantiza que este método sea idem potente. El cliente debe enviar una solicitud en el siguiente formulario:
PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 20
{fielda: 1, fieldc: 2}
Y el servidor puede responder con 204 (Sin contenido) para marcar el éxito. En caso de error no puede actualizar una parte de la estructura. El método PATCH es atómico.
La desventaja de este método es que no todos los navegadores lo admiten, pero esta es la opción más natural en un servicio REST.
Ejemplo de solicitud de parche:
enlace
Aplicación de parches Json
La opción json parece ser bastante completa y una opción interesante. Pero puede ser difícil de implementar para terceros. Tienes que decidir si tu base de usuarios puede manejar esto.
También es algo complicado, porque necesita crear un pequeño intérprete que convierta los comandos en una estructura parcial, que va a utilizar para actualizar su modelo. Este intérprete también debe verificar, si los comandos proporcionados tienen sentido. Algunos comandos se anulan entre sí. (escribe fielda, borra fielda). Creo que desea informar esto al cliente para limitar el tiempo de depuración de su lado.
Pero si tienes tiempo, esta es una solución realmente elegante. Aún debe validar los campos por supuesto. Puede combinar esto con el método PATCH para permanecer en el modelo REST. Pero creo que POST sería aceptable aquí.
Va mal
Si decides optar por la opción PUT, es un poco arriesgado. Entonces al menos no debes descartar el error. El usuario tiene cierta expectativa (los datos se actualizarán) y si rompe esto, le dará a algunos desarrolladores no un buen momento.
Usted podría elegir para marcar hacia atrás: 409 Conflicto o 403 Prohibido. Depende de cómo se mire el proceso de actualización. Si lo ve como un conjunto de reglas (centrado en el sistema), entonces el conflicto será más agradable. Algo así, estos campos no son actualizables. (En conflicto con las reglas). Si lo ve como un problema de autorización (centrado en el usuario), debe devolver prohibido. Con: no estás autorizado a cambiar estos campos.
Aún debe obligar a los usuarios a enviar todos los campos modificables.
Una opción razonable para hacer cumplir esto es establecerlo en un sub-recurso, que solo ofrece los datos modificables.
Opinión personal
Personalmente iría (si no tiene que trabajar con navegadores) para el modelo PATCH simple y luego lo extienda con un procesador de parches JSON. Esto se puede hacer diferenciando en los tipos MIME:
El tipo mime del parche json:
aplicación / json-patch
Y JSON:
aplicación / json-patch
facilita su implementación en dos fases.