Entrevista Backend: ¿Por qué 405 Method Not Allowed debe devolver Allow?

Pregunta

Usted mantiene una API de archivos: GET /v1/files/:id lee un archivo, pero un cliente envía POST o DELETE al mismo recurso. El entrevistador le pide que diseñe la respuesta y explique la diferencia entre 405, 404, 403, OPTIONS y el preflight de CORS. Cubra la coincidencia de rutas, el encabezado Allow, el cuerpo del error, las pruebas y el despliegue.

Contexto y restricciones

• La ruta del recurso coincide con un archivo concreto, pero hoy en día solo GET y HEAD están habilitados.
• Un desajuste de versión del SDK puede causar un método inválido, y un proxy podría reescribirlo o interceptarlo.
• Los clientes que llaman necesitan una respuesta diagnosticable, mientras que los métodos deshabilitados no deben anunciarse como disponibles.
• Si la existencia del recurso es confidencial, el equipo puede usar una política consistente de ocultamiento con 404, documentada en el contrato de la API.

Qué está evaluando el entrevistador

Separar la coincidencia de recursos del despacho de métodos

Haga coincidir primero el host, la ruta, la versión y el identificador de recurso; luego consulte el conjunto de métodos permitidos para ese recurso. Devuelva 404 cuando la ruta no esté presente; devuelva 405 cuando la ruta exista pero el método esté fuera de ese conjunto. La autorización sigue la política de seguridad: un cliente autenticado sin permisos puede recibir 403. No convierta cada falla de autorización en 405.

405 debe incluir Allow

405 significa que el servidor reconoce el método de solicitud pero el recurso de destino no lo soporta. La respuesta debe incluir Allow, listando los métodos actualmente soportados por ese recurso, por ejemplo:

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS
Content-Type: application/problem+json

{"type":"about:blank","title":"Method Not Allowed","status":405,"detail":"Use one of the methods listed in Allow."}

Allow describe la capacidad del recurso. Es diferente de Access-Control-Allow-Methods de CORS, el cual participa en la política de origen cruzado del navegador y no puede reemplazar el contrato de método HTTP expresado por 405.

Modelar OPTIONS por separado

OPTIONS puede consultar sobre opciones de comunicación. Un preflight de CORS del navegador también envía Origin y Access-Control-Request-Method. El éxito del preflight depende de los encabezados de respuesta CORS y de la política de autenticación. No convierta cada solicitud OPTIONS en 405, ni trate a Allow como una lista de autorización CORS.

Preguntas aclaratorias antes de responder

• ¿Existe realmente el recurso? Si no, use 404; si una política de seguridad oculta su existencia, confirme si devuelve consistentemente 404.
• ¿Pueden variar los métodos permitidos según el tenant, el estado del recurso o la versión de la API? La respuesta cambia el contexto utilizado para generar Allow y la clave de caché.
• ¿Reescribirá el gateway los métodos desconocidos y quién es responsable de la generación de Allow? La respuesta define el límite de depuración y la fuente única de la verdad.

Estructura de respuesta en 30 segundos

“La ruta coincidió, pero el método está fuera del conjunto de capacidades del recurso, por lo que devuelvo 405 y listo los métodos que realmente están soportados en Allow. Una ruta inexistente es 404, una denegación de autorización sigue la política de 403, y OPTIONS junto con el preflight de CORS usan encabezados separados. Concluiría con una matriz de métodos, una prueba real en la ruta del gateway y métricas de despliegue.”

Respuesta detallada paso a paso

Defina los métodos permitidos de cada ruta de recurso en un registro auditable, luego permita que el enrutador use ese mismo registro para el despacho y la generación de Allow. Para POST /v1/files/123, devuelva 405 si el recurso existe y POST no está registrado; devuelva 404 si 123 no existe; devuelva 403 para una solicitud coincidente denegada por la política de autorización. HEAD a menudo sigue la capacidad de lectura de GET, pero el comportamiento real del framework es la fuente de la verdad.

El cuerpo del error debe proporcionar un estado estable, un título y una explicación procesable sin exponer trazas de la pila ni detalles de rutas internas. Liste solo los métodos que estén realmente habilitados en Allow; durante un despliegue, no anuncie capacidades de escritura que no estén desplegadas. Si la política de seguridad oculta la existencia del recurso, documente su elección entre 404 y 405, los campos de registro y el comportamiento de reintento del cliente.

Respuesta de muestra de alta calidad

“Primero dejaría que el enrutador establezca si el archivo existe y luego despacharía desde un único registro de métodos. Para un archivo existente que recibe un POST no registrado, devuelvo 405 y coloco GET, HEAD, más un OPTIONS genuinamente soportado, en Allow; devuelvo 404 para un archivo inexistente y sigo la política de autorización para 403. El preflight de CORS usa Access-Control-Allow-Methods, no Allow. El gateway y la aplicación tienen un único responsable para la generación de encabezados. Las pruebas de contrato verifican cada estado y conjunto de métodos, mientras que el despliegue monitorea 405 por método.”

Errores comunes

• Devolver 404 para una ruta existente con un método no soportado, impidiendo que los clientes distingan una URL incorrecta de un método incorrecto.
• Devolver 405 sin Allow, impidiendo que los clientes descubran los métodos soportados y violando la semántica HTTP.
• Usar Access-Control-Allow-Methods en lugar de Allow, confundiendo la capacidad HTTP con los permisos de origen cruzado del navegador.
• Reclasificar cada falla de autorización como 405, lo que corrompe las auditorías de seguridad, el monitoreo y el comportamiento del cliente.
• Permitir que el gateway y la aplicación generen conjuntos de Allow diferentes, produciendo respuestas inconsistentes tras el almacenamiento en caché del proxy.

Error, motivo, corrección

Tratar 405 como una falla genérica, omitir Allow o usar el encabezado CORS como Allow deja a los clientes sin una acción siguiente. Corrija el flujo haciendo coincidir primero el recurso, generando el estado y los encabezados a partir de un único registro de métodos, y probando 404, 403, 405 y preflight por separado.

Implementación en producción

Coordinar rutas y proxies

Pase el 405 y el Allow de la aplicación a través del gateway o defina un único responsable en el gateway y evite sobreescrituras duplicadas. Mantenga una matriz de métodos por versión de API, incluidos los requisitos de almacenamiento en caché, idempotencia, autenticación y reintentos. Si un proxy degrada los métodos desconocidos a GET, corrija esa política primero; de lo contrario, la aplicación nunca verá el método real.

Observabilidad y compatibilidad

Registre el método de la solicitud, la ruta normalizada, la versión de la ruta, el estado de la respuesta y el conjunto final de Allow sin registrar el contenido de los archivos. Tras recibir 405, el cliente debe dejar de reintentar a ciegas el mismo método y usar un método soportado por contrato o actualizar su SDK. Para clientes heredados, observe el uso incorrecto en los registros y la documentación antes de endurecer el comportamiento mediante un cambio versionado.

Lista de verificación de validación

Pruebas de contrato

Construya una matriz de métodos para cada recurso cubriendo: éxito para métodos registrados, 405 para un método no registrado, 404 para una ruta inexistente, 403 para denegación de autorización e igualdad entre Allow y la ruta real. Aserte el estado, el conjunto de métodos del encabezado, el tipo de contenido y los campos del cuerpo de error.

Integración y regresión

Use un cliente HTTP real para verificar juntos el comportamiento del gateway, el balanceador de carga y la aplicación. Pruebe OPTIONS y el preflight de CORS por separado, confirmando que Access-Control-Allow-Methods no reemplace a Allow. Durante el despliegue, active alertas sobre la tasa de 405, la distribución de métodos y las fallas de análisis del cuerpo de error.

Preguntas de seguimiento y respuestas

¿Cuándo se puede devolver 404 en lugar de 405?

Devuelva 404 cuando la ruta realmente no exista o cuando una política de seguridad oculte intencionalmente la existencia del recurso. Aplique esa opción de manera consistente para la clase de recurso y documéntela para los clientes, los registros y el monitoreo; diferentes nodos no deben devolver aleatoriamente 404 o 405.

¿Debe Allow incluir siempre OPTIONS?

Inclúyalo solo cuando el recurso realmente acepte OPTIONS. Si el framework maneja OPTIONS automáticamente, verifique que su respuesta coincida con el contrato de ruta de la aplicación; no agregue un método no implementado solo por completitud visual.

¿Cómo deben funcionar las capacidades dinámicas?

Cuando la capacidad del método varía según el tenant, la versión o el estado del recurso, genere Allow a partir del contexto actual de la solicitud e incluya todas las dimensiones de capacidad en la clave de caché. Un valor predeterminado más seguro es limitar el almacenamiento en caché intermediario de 405 o establecer una política de caché explícita.

Rúbrica de evaluación

• Precisión semántica: explica cuándo aplica 405 y por qué Allow es obligatorio.
• Límites claros: distingue 404, 403, OPTIONS, CORS y el ocultamiento de seguridad.
• Implementación práctica: ofrece elecciones concretas sobre registro, proxy, cuerpo de error y observabilidad.
• Verificación completa: cubre matrices de métodos, rutas HTTP reales, métricas de despliegue y regresión.
• Conciencia de riesgos: evita anuncios falsos de métodos, fugas de información y discrepancias entre el gateway y la aplicación.

Referencias

• MDN: 405 Method Not Allowed
• MDN: Allow header
• Postman: HTTP Error 405
• JustAcademy: REST API interview questions

Consejo para responder

Comience con “el recurso coincidió, el método no está soportado, se devuelve 405”, y luego proporcione el conjunto real de Allow. Distinga 404, 403, OPTIONS y CORS, y finalice con pruebas de matriz de métodos y consistencia de proxies.

Conclusión en una sola frase

405 indica que la combinación de recurso y método no es válida, mientras que Allow informa al cliente qué métodos son válidos actualmente; juntos forman un contrato HTTP diagnosticable.