Resumen

  • Accept-Patch enumera los tipos de medios que un recurso acepta como documentos de parche. Su presencia señala capacidad PATCH, pero no autentica al solicitante, no concede acceso de escritura y no valida el cambio concreto.
  • Descubrimiento, lenguaje de parche, precondición de estado y autorización son decisiones distintas. El campo ayuda a preparar una solicitud; solo la solicitud real, evaluada en su contexto, puede resolver las demás.

Una respuesta OPTIONS enumera application/json-patch+json y application/merge-patch+json. El cliente ya sabe que el recurso anuncia dos gramáticas. No sabe si su cuenta puede escribir. Tampoco sabe si la versión que leyó sigue vigente, si las operaciones son admisibles ni si una regla comercial las rechazará. No ha recibido una credencial.

El riesgo nace al convertir un anuncio formal en una propiedad única llamada «editable». Accept-Patch llega desde el servidor, está registrado y suele acompañar a Allow. Sin embargo, RFC 5789 define por separado la publicidad de formatos y la obligación de autorizar las solicitudes.

La capacidad no sustituye a las otras decisiones

PATCH se estandarizó porque PUT representa el reemplazo completo, mientras que una actualización parcial necesita instrucciones cuya semántica depende de un tipo de medio. La URI objetivo nombra el recurso. Content-Type nombra el lenguaje del documento. Una precondición relaciona la operación con un estado observado. La autenticación y el control de acceso deciden si el principal puede actuar.

Accept-Patch funciona antes de esa cadena. Su valor es una lista de tipos de medios con parámetros opcionales. Debería aparecer en la respuesta OPTIONS de un recurso que soporte PATCH. Si aparece en respuesta a cualquier método, implica que PATCH está permitido como capacidad del recurso; cada tipo listado se anuncia como formato aceptado allí.

Ese «permitido» no significa «permitido para todos». Las consideraciones de seguridad de RFC 5789 exigen autorizar solicitudes y mencionan control de acceso y autenticación. Por eso una respuesta GET pública puede mostrar formatos aunque un PATCH anónimo obtenga 401 o 403. Dos usuarios pueden recibir el mismo anuncio y tener alcances de campo distintos.

PATCH también puede figurar en Allow sin Accept-Patch. Entonces se comunica el método, no la lista de documentos. La aparición del campo fuera de OPTIONS conserva la señal implícita de método. Ninguno de los casos es una promesa temporal: RFC 9110 dice que el conjunto real de métodos se determina en cada solicitud y puede cambiar dinámicamente.

El tipo de medio define el programa

No existe una gramática PATCH predeterminada que todos deban implementar. El servidor debe comprobar que el documento recibido sea apropiado para el recurso. El erratum verificado 3169 refuerza la regla: la semántica procede del tipo de medio, no de la capacidad genérica de analizar JSON o XML. Tratar application/json como parche sin una especificación convertiría la interoperabilidad en una convención privada.

JSON Patch usa application/json-patch+json y una matriz ordenada de operaciones: add, remove, replace, move, copy y test. JSON Merge Patch usa application/merge-patch+json y se parece al documento final: compara miembros, agrega o reemplaza valores y reserva null para eliminar.

Los dos trabajan con JSON, pero no expresan lo mismo. test puede fijar una hipótesis puntual dentro de JSON Patch. Merge Patch resulta breve para objetos, aunque encaja mal cuando null es un valor real o se requieren cambios detallados en matrices. Anunciar ambos no los vuelve equivalentes ni autoriza al cliente a convertir uno en otro.

La elección queda explícita en Content-Type. Un SDK no debería escoger el primer elemento por orden ni cambiar únicamente la etiqueta de un cuerpo ya construido. Los parámetros pueden importar y la aplicación puede saber producir con seguridad un solo lenguaje.

Un rechazo también puede enseñar

Que el formato esté anunciado no garantiza el éxito. RFC 5789 separa varias condiciones: 400 para un documento mal formado; 415 para un tipo no soportado; 422 para instrucciones válidas en sintaxis pero imposibles de procesar; 404 cuando el objetivo no existe y el formato no puede aplicarse al vacío; 409 por conflictos de estado o concurrencia; y 412 cuando falla una precondición explícita.

La respuesta 415 debería incluir Accept-Patch. El servidor rechaza el intento y, a la vez, explica qué alternativas entiende. El campo no acepta retroactivamente el cuerpo, no permite cambiar solo Content-Type y no asegura que una nueva solicitud supere autenticación, autorización, condición o reglas de negocio.

El cliente puede conservar el rechazo, presentar la lista y decidir si sabe construir otra solicitud semánticamente equivalente. Es una operación nueva, bajo estado y política nuevos. El descubrimiento evita adivinanzas, pero no ordena reintentar.

If-Match habla del estado, no de la identidad

Muchos parches parten de una versión concreta. Si dos clientes trabajan sobre la misma base, el segundo documento puede dañar un estado que ya cambió. RFC 5789 recomienda una solicitud condicional y ofrece un ETag fuerte en If-Match como ejemplo.

RFC 9110 hace que el servidor evalúe If-Match antes del método mediante comparación fuerte. Si la representación ya no coincide, 412 evita que el servidor improvise una rebase. La técnica combate la actualización perdida.

Pero conocer un ETag no concede privilegios. Un actor no autorizado puede haber leído el valor correcto y un usuario autorizado puede enviar uno obsoleto. El sistema evalúa tanto el acceso como la precondición. Accept-Patch no resuelve ninguna de las dos.

IANA registra PATCH como método no seguro y no idempotente. Una solicitud particular puede diseñarse de forma idempotente, pero depende de sus operaciones. Repetir un append no equivale a repetir un replace protegido. El anuncio de tipos no describe el efecto de reintentar el documento futuro.

Todo o nada empieza al ejecutar

RFC 5789 exige aplicar el conjunto completo de cambios de forma atómica. El servidor no puede exponer una representación parcialmente modificada; si el documento entero falla, no debe permanecer ningún cambio.

RFC 6902 lo muestra con una operación test fallida: todo el JSON Patch queda sin aplicar. La atomicidad es un límite de ejecución, no un privilegio derivado del anuncio. Además, PATCH puede tener efectos definidos por la aplicación sobre otros recursos, por lo que el compromiso debe abarcar los elementos directamente afectados.

Una implementación ordenada autentica, autoriza objetivo y operaciones, valida Content-Type, analiza la gramática correspondiente, evalúa precondiciones y reglas de dominio, prepara los cambios y los confirma juntos. Leer Accept-Patch no inicia esa transacción, no bloquea la versión y no reserva capacidad.

Los cachés reaccionan al cambio, no al descubrimiento

RFC 9111 obliga a un caché atravesado a invalidar el URI objetivo tras una respuesta no errónea a un método inseguro. Location y Content-Location del mismo origen pueden ser candidatos adicionales; otro origen no puede ser invalidado mediante esa regla.

Esas consecuencias pertenecen al PATCH realizado. Un OPTIONS con Accept-Patch no modifica y no debe actuar como purga. Incluso después del éxito, la invalidación solo alcanza los cachés del camino, no garantiza coherencia global ni amplía la autoridad del solicitante.

La integridad criptográfica conserva el anuncio

RFC 9421 permite firmar componentes seleccionados de un mensaje HTTP. Si el perfil cubre Accept-Patch, la verificación puede proteger su integridad y asociarlo a una clave. Aun así, el perfil de la aplicación debe definir las claves, componentes y reglas de confianza.

Un protocolo adicional podría ligar firma, principal, método y objetivo para autorizar. Esa autoridad vendría del protocolo adicional, no del listado. La firma conserva lo que el servidor anunció; no convierte los formatos en un permiso de escritura.

Un modelo operativo verificable

El cliente debería guardar por separado el recurso y la hora de observación, la señal de PATCH en Allow, la lista exacta de tipos y parámetros, el validador de la representación de base y el contexto de credenciales de la nueva solicitud. Una interfaz puede reunirlos, pero el registro no debe reducirlos a un booleano.

El servidor puede usar OPTIONS para describir una capacidad relativamente estable y decidir la autorización al llegar PATCH. Después valida el tipo, interpreta el lenguaje, comprueba If-Match y reglas de dominio, y confirma todo atómicamente. Un 415 puede informar sin comprometer el resultado de otro intento.

Los ensayos deben combinar casos: Allow sin lista; lista en GET; anuncio idéntico para cuentas con derechos distintos; If-Match antiguo; JSON genérico rechazado; diferencias intencionadas entre JSON Patch y Merge Patch; test fallido sin cambios; y anuncio firmado seguido de 403.

La página de errata actual muestra tres correcciones verificadas y una rechazada. El erratum 5521 retira Content-Location del ejemplo 204, por lo que esa versión antigua no debe sostener decisiones. El 7513 corrige un enlace sin cambiar la clasificación. El 3419, rechazado, no reescribe el estándar.

Fuentes