HTML4 / XHTML1 solo permite GET y POST en formularios, ahora parece que HTML5 hará lo mismo. Hay una propuesta para agregar estos dos, pero no parece estar ganando terreno. ¿Cuáles fueron las razones técnicas o políticas para no incluir PUT y DELETE en el borrador de especificación HTML5?
Esta es una pregunta fascinante. Las otras respuestas aquí son todas especulativas, y en algunos casos son totalmente incorrectas. En lugar de escribir mi opinión aquí, realicé algunas investigaciones y encontré fuentes originales que explican por qué delete y put no forman parte del formulario estándar de HTML5.
Como resultado, estos métodos fueron incluidos en varios borradores tempranos de HTML5 (!), pero luego se eliminaron en borradores posteriores . Mozilla realmente implementó este en una versión beta de Firefox , también.
¿Cuál fue la razón para eliminar estos métodos del borrador? El W3C trató este tema en informe de error 10671 . Mike Amundsen argumentó a favor de este apoyo:
Ejecutar PUT y DELETE para modificar recursos en el servidor de origen es sencillo para los navegadores web modernos que utilizan el objeto XmlHttpRequest. Para interacciones de navegador sin guiones esto no es tan simple. [...]
Este patrón se requiere tan a menudo que varios marcos / bibliotecas web de uso común han creado una solución "incorporada". [...]
Otras consideraciones:
- El uso de POST como un túnel en lugar de usar PUT / DELETE puede llevar a errores en el almacenamiento en caché (por ejemplo, las respuestas de POST son almacenable en caché , las respuestas PUT no lo son (6), las respuestas BORRADAS no lo son (7))
- El uso de un método no idempotente (POST) para realizar una operación idempotente (PUT / DELETE) complica la recuperación debido a fallas en la red (por ejemplo, "¿Es seguro repetir esta acción?").
- [...]
Vale la pena leer todo su post.
Tom Wardrop también hace un punto interesante:
HTML está inextricablemente vinculado a HTTP. HTML es la interfaz humana de HTTP. Por lo tanto, es automáticamente cuestionable por qué HTML no admite todos los métodos relevantes en la especificación HTTP. ¿Por qué pueden las máquinas PONER y BORRAR recursos, pero los humanos no pueden? [...]
Es contradictorio que, si bien el HTML hace todo lo posible para garantizar el marcado semántico, hasta la fecha no ha realizado ningún esfuerzo para garantizar las solicitudes HTTP semánticas.
El error se cerró finalmente como No se solucionará por Ian Hickson, con el siguiente razonamiento:
PONER como método de formulario no tiene sentido, no querría PONER una carga útil de formulario. BORRAR solo tiene sentido si no hay carga útil, por lo que tampoco tiene mucho sentido con los formularios.
Sin embargo, ¡ese no es el final de la historia! El problema se cerró en el rastreador de errores del W3C y se escaló al rastreador de problemas del Grupo de trabajo HTML:
En este punto, parece que la razón principal por la que no hay soporte para estos métodos es simplemente que nadie se ha tomado el tiempo para escribir una especificación completa para él.
GET y POST tienen una lógica clara de contenido neutral. GET es recuperar el contenido de una URL de una manera que es seguro repetir y posiblemente almacenar en caché. POST es hacer algo de una manera que no sea seguro repetir, ejecutar de forma especulativa o caché.
No hubo una justificación similar para PUT o DELETE. Ambos están completamente cubiertos por POST. La creación o destrucción de un recurso son operaciones que no son seguras de repetir, no son seguras de ejecutar especulativamente y no deben almacenarse en caché. No se necesitan semánticas especiales adicionales para ellos.
Básicamente, no hay ningún beneficio.
Esto se planteó en 2010 como Error 10671 considere la posibilidad de agregar soporte para PUT y DELETE como métodos de formulario .
Hubo una cantidad moderada de rechazo para esta "característica" y algo de mano dura, pero eventualmente esto se escaló como dos problemas en el rastreador de errores de los Grupos de Trabajo:
El problema ISSUE-196 resultó en una decisión de consenso para no realizar ningún cambio en la especificación ya que la especificación HTML no restringe actualmente cómo se manejan las respuestas a las solicitudes POST. Creo que este problema en particular surgió al intentar conciliar los patrones de redireccionamiento de POST que se usan comúnmente y cómo los servidores ReSTful a menudo brindan respuestas 2xx con mensajes cortos en lugar de algo útil para representar en un navegador.
El problema ISSUE-195 se presentó a los presidentes. Cameron Jones se ofreció como voluntario para escribir una propuesta de cambio el 18 de enero de 2012, que presentó para convertirse en el primer borrador de trabajo el 29 de mayo de 2014. El borrador pasará por el Proceso de recomendaciones del W3C .
Con un poco de suerte, esto pronto se convertirá en una recomendación de W3C e implementada por los proveedores de navegadores, y sería un gran paso adelante para eliminar los bloqueadores para producir servicios ReSTful unificados, semánticos y compatibles con el navegador. Me imagino que esto provocará una interesante evolución en los patrones de servicio. Hay una buena charla de Jon Moore - API de Hypermedia que vale la pena ver, esto me llamó la atención, pero cayó en el primer obstáculo (este). / p>
Entiendo que los navegadores no saben qué hacer una vez que envían un PUT o un BORRADO. Un POST se redirigirá a una página apropiada normalmente, pero PUT y DELETE normalmente no lo hacen. Esto los hace apropiados para llamar a través de ajax o un programa nativo, pero no desde un formulario de navegador web.
No puedo evitarlo ahora, pero recuerdo haber leído una de las listas de correo html5 cuando estaban discutiendo esto.
Creo que vale la pena mencionar la primera aparición de formularios html en RFC1866 (Sección 8.1) . Aquí el atributo del método se define como lo siguiente:
METHOD selects a method of accessing the action URI. The set of applicable methods is a function of the scheme of the action URI of the form. See 8.2.2, "Query Forms: METHOD=GET" and 8.2.3, "Forms with Side-Effects: METHOD=POST".
Otras explicaciones se encuentran en Sección 8.2.2 - GET y Sección 8.2.3 - POST
Tenga en cuenta que HTML 2.0 (noviembre de 1995) se especificó antes HTTP 1.0 (Mayo de 1996). Entonces, todos usaron HTTP solo con GET (a partir de HTTP 0.9) o con la extensión POST. Pero solo unos pocos servidores web admitieron PUT y DELETE (como se indica en el HTTP 1.0 Apéndice ).
Si piensa en cómo podría haber evolucionado el desarrollo de Berners-Lee de la web semántica, parece claro que pasó de los problemas reales a un concepto general. Primero quiso compartir documentos. Por lo tanto, necesitaba marcado. Luego quería consultar el contenido de las bases de datos, por lo que necesitaba formularios. Luego quiso poner nuevos datos en la base de datos. Así que usó formas con GET y POST. Después de eso, puede haberse dado cuenta de que podía realizar todas las operaciones de CRUD con datos remotos, por lo que HTTP se extendió pero nunca HTML porque era demasiado tarde (solo unos pocos servidores admitían las nuevas operaciones de CRUD).
Simplemente arrojando una suposición descabellada, pero probablemente porque HTTP no es muy bueno con el control de acceso en el mejor de los casos, y lo último que todos necesitan es incluso más formas para que las URL maliciosas se comprometan Un sitio web y / o una aplicación mal asegurados.
HTTP no es realmente un buen protocolo para transferencias de archivos que no sean la descarga del servidor al cliente. Utilice FTP - o mejor aún, SFTP.
Obtener y publicar son formatos de transmisión de los datos de la solicitud.
Supongo que está preguntando sobre cómo enviar el formulario a un servicio RESTFUL. Pero no tiene sentido cambiar el estándar de solicitud http para hacer suposiciones el propósito de la solicitud http. La información sobre el propósito con el que se llena la solicitud se maneja mejor en los campos de entrada.
Tener una dirección y obtener y publicar le permite al servidor interpretar la solicitud y sus valores de entrada correctamente. Desde allí, los valores de entrada le permiten hacer solicitudes abiertas al servidor y hacer lo que quiera. Por ejemplo, puede tener un campo cuyos valores son "poner" y "eliminar"
Los elementos HTML están restringidos a métodos de formulario y no a métodos de texto. Para otros métodos que no sean HTMLName, el programa real se ha diseñado utilizando nada más que JavaScript y Mobble para que se pregunte "por qué no tenemos nuestro propio navegador web". Módulos de terceros Agregue otras funciones útiles <| endoftext |> Vea cómo el mundo rodea ahora ve cómo podría sentirse sobre la tecnología mientras vemos cómo se desarrolla el Proyecto GOV.UK. Jerarquía y medios Página 1 de 4 Es... Lee mas