Planteamiento y contexto
Eres responsable de una API de perfil de equipo. Un cliente puede cambiar solo displayName o enviar un perfil completo, y los reintentos móviles son comunes. Explica cuándo usar PUT o PATCH, cómo definir los campos omitidos y null, y cómo manejar conflictos, atomicidad, reintentos idempotentes y compatibilidad.
La lista de entrevistas de backend de Greenroom para 2026 incluye explícitamente la diferencia entre PUT y PATCH, la idempotencia y la elección del método. La RFC 5789 define una entidad PUT como una nueva representación completa del recurso, mientras que una entidad PATCH contiene instrucciones para aplicar al recurso actual. Esta pregunta no está vinculada a una empresa específica.
Qué evalúan los entrevistadores
Una respuesta promedio memoriza que “PUT es completo, PATCH es parcial”. Una respuesta sólida define el contrato del recurso, indica si los campos omitidos permanecen sin cambios, indica si null limpia un campo, explica If-Match y establece si una solicitud fallida deja la totalidad del cambio sin aplicar. Las preguntas de seguimiento suelen abarcar solicitudes duplicadas, respuestas perdidas, campos desconocidos, eventos de auditoría y clientes antiguos.
La señal principal es conectar la semántica de HTTP con las actualizaciones de la base de datos y el control de concurrencia, en lugar de tratar a PATCH como un PUT más pequeño.
Preguntas aclaratorias
- ¿Puede PUT crear un recurso? Este planteamiento actualiza un perfil existente; si se permite la creación en una URI estable, define la propiedad y el comportamiento ante solicitudes duplicadas.
- ¿Envía el cliente un recurso completo o un documento de cambios? Utiliza PUT para una representación completa y PATCH para operaciones de campo o una representación parcial.
- ¿Qué significan la omisión y
null? Aquí la omisión preserva el valor ynulllimpia los campos que admiten valores nulos; los campos no anulables lo rechazan. - ¿Pueden las actualizaciones concurrentes sobrescribirse entre sí? Este planteamiento rechaza la sobrescritura silenciosa y requiere
ETag/If-Matcho una condición de versión en la base de datos. - ¿Existen efectos secundarios? La indexación de búsqueda, los eventos de auditoría y las notificaciones deben seguir el estado confirmado; los efectos asíncronos no forman parte de la atomicidad de HTTP.
Respuesta de 30 segundos
“Defino PUT como el reemplazo de un recurso con una representación completa, para clientes que poseen una instantánea completa. PATCH transporta cambios parciales como una actualización de displayName. PATCH debe definir la omisión frente a null y rechazar versiones obsoletas en lugar de permitir que un formulario antiguo sobrescriba datos nuevos. El servidor valida todo el documento y lo aplica atómicamente en una sola transacción de base de datos, para luego emitir un evento asíncrono con versión. Los clientes reintentan con la misma semántica de solicitud y If-Match. Si el cambio es un comando en lugar de una actualización de recurso, utilizo un endpoint de acción en lugar de sobrecargar PATCH.”
Respuesta paso a paso
Paso 1: Escribir ambos métodos como contratos de recursos
| Dimensión | PUT | PATCH |
|---|---|---|
| Significado de la solicitud | El cuerpo es la nueva representación completa del recurso | El cuerpo es una instrucción de cambio o representación parcial aplicada al recurso actual |
| Campo omitido | Por lo general significa que el cliente proporcionó el estado completo; no debe preservar silenciosamente campos antiguos | Debe significar explícitamente preservar o no válido |
| Idempotencia | Repetir la misma representación debería alcanzar el mismo estado del recurso | No está garantizada por el método, pero un documento de patch específico puede ser idempotente |
| Uso típico | Sincronizar una instantánea completa de un editor o reemplazar configuración | Cambiar un campo con JSON Merge Patch o JSON Patch |
La propiedad clave de PUT no es el tamaño del cuerpo; es la afirmación del cliente de que la representación está completa. Si un cliente solo conoce unos pocos campos pero envía un PUT, el servidor puede interpretar los campos faltantes como eliminación o valores predeterminados. PATCH no es automáticamente seguro: la validación, la autorización y los efectos secundarios siguen aplicando.
Paso 2: Definir el documento PATCH y tres estados de campo
PATCH /v1/teams/t_123/profile HTTP/1.1
Content-Type: application/merge-patch+json
If-Match: "profile-v17"
{"displayName":"Design Platform","avatarUrl":null}Este planteamiento utiliza un estilo JSON Merge Patch: displayName se reemplaza, avatarUrl: null limpia un campo anulable y un campo omitido permanece sin cambios. Si el negocio necesita operaciones de arreglo a nivel de elemento, movimientos o pruebas, utiliza en su lugar una lista restringida de operaciones de JSON Patch.
Analiza sintácticamente el documento primero, luego valida una lista de permitidos, tipos, longitudes, autorización e invariantes de dominio. Nunca mapees rutas JSON arbitrarias del cliente directamente a columnas de la base de datos. Los campos desconocidos pueden rechazarse o ignorarse dentro de un contrato versionado, pero el comportamiento debe ser fijo y estar documentado.
Paso 3: Prevenir la sobrescritura silenciosa con una condición de versión
GET /v1/teams/t_123/profile HTTP/1.1
ETag: "profile-v17"
PATCH /v1/teams/t_123/profile HTTP/1.1
If-Match: "profile-v17"
Content-Type: application/merge-patch+json
{"displayName":"Design Platform"}La actualización de la base de datos incluye un predicado de versión: solo la versión 17 puede escribir y avanzar a la 18. Una discrepancia devuelve 412 Precondition Failed; el cliente vuelve a leer, muestra un conflicto o regenera su patch. No puede forzar una versión antigua sobre datos más nuevos. Si If-Match es obligatorio y falta, 428 Precondition Required puede hacer explícita la política de concurrencia.
PATCH también debe ser atómico como documento: que el campo A tenga éxito mientras el campo B falla no es una media actualización aceptable. La transacción, la fase de validación y las restricciones de unicidad deciden si el cambio se confirma. Los eventos con efectos secundarios deben escribirse en una outbox y publicarse después de la confirmación con la versión del recurso.
Paso 4: Manejar solicitudes duplicadas y resultados desconocidos
Las solicitudes PUT repetidas con la misma representación completa convergen al mismo estado. PATCH tiene esa propiedad solo cuando la operación es repetible: establecer displayName es idempotente, mientras que increment seats by 1 no lo es. Un PATCH no idempotente necesita un ID de solicitud, una condición de versión o una operación que exprese un estado objetivo.
Tras una falla de red, el cliente no sabe si el servidor confirmó la transacción. Utiliza un ID de solicitud estable con una huella digital y un resultado registrados, o reintenta con If-Match y un estado objetivo. No repitas a ciegas un patch que añade efectos secundarios. Después de que el recurso se confirma, los consumidores de eventos manejan la indexación y las notificaciones y desduplican por ID de evento.
Paso 5: Decidir cuándo PUT/PATCH no es la forma adecuada
“Publicar el perfil”, “recalcular permisos” y “enviar una invitación” son comandos, no representaciones de recursos de reemplazo o parciales. Un endpoint de acción como POST /profile:publish expresa permisos, auditoría, reintentos y estado asíncrono con mayor claridad. Un comando con forma de PATCH hace que los clientes malinterpreten la ejecución duplicada y los efectos secundarios.
La alta contención o las transacciones entre recursos también pueden necesitar un comando de dominio. Cambiar un miembro de editor a propietario requiere verificaciones de cuota y auditoría; cambiar una sola cadena con PATCH no expresa esas invariantes.
Ejemplo de respuesta de alta calidad
“Expondría tanto PUT como PATCH con contratos diferentes. PUT acepta una representación completa del perfil de equipo; un campo omitido es un error de contrato o un valor predeterminado explícito, nunca un ‘dejar sin cambios’ accidental. PATCH acepta un Merge Patch restringido y solo campos en la lista de permitidos; la omisión preserva un valor y null lo limpia solo cuando el campo es anulable.
“Ambos métodos utilizan ETag y If-Match. La base de datos realiza una actualización condicionada por versión y devuelve 412 ante una discrepancia, de modo que un cliente antiguo no puede sobrescribir datos más nuevos. El documento PATCH se valida por completo y se aplica en una sola transacción; una outbox publica un evento de indexación versionado tras la confirmación. Un PATCH para establecer campos puede ser idempotente; los incrementos necesitan un ID de solicitud, una condición o una operación de estado objetivo. Publicar e invitar son acciones POST porque tienen efectos secundarios explícitos. Probaría duplicados, respuestas perdidas, omisión/null, conflictos, campos desconocidos, fallas parciales y compatibilidad con clientes antiguos.”
Errores comunes
- Síntoma → Llamar a PUT “actualizar cualquier campo” → Por qué falla → Los emisores de solicitudes no pueden saber si los campos omitidos desaparecen → Solución → Haz que PUT sea una representación completa y usa PATCH para cambios parciales.
- Síntoma → Afirmar que PATCH es inherentemente idempotente → Por qué falla → La RFC 5789 no lo garantiza; los incrementos repetidos cambian el estado → Solución → Haz que solo los patches de estado objetivo sean repetibles y añade condiciones o desduplicación a otras operaciones.
- Síntoma → Mapear claves JSON arbitrarias a columnas → Por qué falla → Se omiten la autorización de campos, la validación de tipos y las invariantes entre campos → Solución → Utiliza una lista de permitidos y validación de dominio explícita.
- Síntoma → Dejar que gane el último escritor tras un conflicto de versiones → Por qué falla → Un formulario antiguo sobrescribe silenciosamente datos nuevos → Solución → Usa
If-Matchy un predicado de versión, devolviendo 412 ante un conflicto. - Síntoma → Llamar al servicio de búsqueda sincrónicamente después de confirmar → Por qué falla → Una respuesta perdida o una caída del proceso divide el recurso y el índice → Solución → Escribe en una outbox dentro de la transacción y publica de forma asíncrona con desduplicación por ID de evento.
Preguntas de seguimiento y respuestas
¿Qué pasa si el producto requiere que los campos omitidos en PATCH limpien los valores?
Eso convierte a PATCH en otro contrato de representación completa y lo confunde con PUT. Usa PUT, o define un tipo de medio de reemplazo de conjunto de campos con un nombre claro; lo importante es hacer explícita la consecuencia de un campo omitido.
¿Qué sucede si dos clientes leen la versión 17 y editan campos diferentes?
Devuelve 412 por defecto y deja que el cliente fusione y reintente, porque el servidor no puede asumir que las ediciones son independientes. La fusión a nivel de campo es segura solo cuando el dominio lo permite explícitamente y el patch incluye versiones de campo u operaciones de prueba.
¿Qué ocurre si PATCH desencadena facturación o notificaciones?
Separa la actualización del recurso y el efecto secundario en pasos auditables: confirma el recurso y la outbox juntos, luego deja que un consumidor idempotente procese el evento. Si el efecto secundario requiere la intención explícita del usuario, conviértelo en un comando POST separado con un estado de operación asíncrono.