Compruebe si un método HTTP es seguro o idempotente

Clasifique un método HTTP estándar mediante las propiedades de seguridad e idempotencia definidas por la semántica HTTP. Introduzca un método como GET, POST, PUT, PATCH o DELETE y obtenga el nombre normalizado, dos resultados booleanos independientes y una clasificación conjunta concisa. El comprobador reconoce los nueve métodos definidos en las especificaciones principales de semántica HTTP y PATCH, ignora mayúsculas, minúsculas y espacios circundantes, y rechaza los nombres desconocidos en lugar de atribuir propiedades a métodos de extensión.

Distinga seguridad de idempotencia

La seguridad y la idempotencia expresan garantías diferentes. Un método seguro está destinado a recuperar información o comunicar opciones, no a solicitar un cambio de estado en el servidor de origen. La idempotencia abarca más casos: significa que varias solicitudes idénticas tienen el mismo efecto previsto en el servidor que una sola solicitud. PUT y DELETE son idempotentes aunque no sean seguros, porque reemplazar repetidamente una representación por la misma representación, o solicitar varias veces la eliminación del mismo recurso, no introduce un efecto previsto nuevo en cada ocasión. GET, HEAD, OPTIONS y TRACE son seguros. La semántica HTTP también establece que todo método seguro es idempotente, por lo que esos métodos reciben la clasificación conjunta `safe_and_idempotent`. La respuesta presenta `safe` e `idempotent` por separado para que el código de políticas no tenga que deducir una propiedad a partir de una etiqueta. También devuelve el campo `classification`, útil para mostrar, registrar o bifurcar decisiones. Estas propiedades describen la semántica estandarizada de la solicitud, no garantizan que una implementación concreta carezca de errores o efectos secundarios incidentales.

Interprete correctamente los reintentos

POST y PATCH se clasifican como métodos que no son seguros ni idempotentes en sus definiciones generales. Una API concreta puede diseñar una operación POST o PATCH que admita reintentos, quizá mediante una clave de idempotencia o una solicitud condicional, pero ese contrato de aplicación no altera la propiedad estandarizada predeterminada del método. Use este resultado como referencia del protocolo y aplique después cualquier garantía adicional documentada expresamente por la API que consume.

Valide el método antes de aplicar una política

Inferir las propiedades de un método de extensión a partir de su nombre podría autorizar un reintento peligroso o impedir una operación válida. Si su sistema utiliza un método de extensión, consulte la especificación que lo registra o define y trátelo mediante una política explícita. El algoritmo no realiza solicitudes de red ni observa servidores, rutas, cachés, proxies o cuerpos de solicitud reales. El comprobador acepta los nombres estándar CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT y TRACE. La entrada se recorta y se convierte a mayúsculas, por lo que valores como ` get ` y `patch` se normalizan sin cambiar su significado. Cualquier otro valor genera un error `invalid_input`. Este comportamiento estricto es importante porque los tokens de método HTTP son extensibles: WebDAV y otros protocolos definen métodos adicionales, y las API privadas pueden introducir tokens propios. Es determinista y sirve para linters, comprobaciones de documentación de API, configuración de middleware de reintentos y herramientas didácticas en el navegador. El ejecutor del navegador y el controlador de la API comparten la misma lógica; una solicitud API usa el precio base publicado de $0.002.