as de información a través de archivos (XML, HTML…) en la World Wide
Web. Fue desarrollado por el World Wide Web Consortium y la Internet
Engineering Task Force, colaboración que culminó en 1999 con la
publicación de una serie de RFC, siendo el más importante de ellos el
RFC 2616 que especifica la versión 1.1. HTTP define la sintaxis y la
semántica que utilizan los elementos de software de la arquitectura web
(clientes, servidores, proxies) para comunicarse.
HTTP es un protocolo sin estado, por lo que no guarda ninguna
información sobre conexiones anteriores. El desarrollo de aplicaciones
web necesita frecuentemente mantener estado. Para esto se usan
las cookies, que es información que un servidor puede almacenar en el
sistema cliente. Esto le permite a las aplicaciones web instituir la noción
de sesión, y también permite rastrear usuarios, ya que
las cookies pueden guardarse en el cliente por tiempo indeterminado.
Descripción
Es un protocolo orientado a transacciones y sigue el esquema petición-
respuesta entre un cliente y un servidor. El cliente (se le suele llamar
"agente de usuario", del inglés user agent) realiza una petición enviando
un mensaje, con cierto formato al servidor. El servidor (al que es común
llamarle servidor web) le envía un mensaje de respuesta. Ejemplos de
cliente son los navegadores web y las arañas web (también conocidas
por su término inglés, webcrawlers).
Mensajes
Los mensajes HTTP son en texto plano, lo que lo hace más legible y fácil
de depurar. Sin embargo, esto tiene el inconveniente de hacer los
mensajes más largos. Los mensajes tienen la siguiente estructura:
Línea inicial (termina con retorno de carro y un salto de línea) con
Para las peticiones: la acción requerida por el servidor
(método de petición) seguido de la URL del recurso y la
versión de HTTP que soporta el cliente.
Para respuestas: la versión del HTTP usado seguido
del código de respuesta (que indica qué ha pasado con la
petición seguido de la URL del recurso) y de la frase
asociada a dicho retorno.
Las cabeceras del mensaje que terminan con una línea en blanco.
Son metadatos. Estas cabeceras le dan gran flexibilidad al
protocolo.
Cuerpo del mensaje. Es opcional. Su presencia depende de la línea
anterior del mensaje y del tipo de recurso al que hace referencia la
URL. Típicamente tiene los datos que se intercambian cliente y
servidor. Por ejemplo, para una petición podría contener ciertos
datos que se quieren enviar al servidor para que los procese. Para
una respuesta podría incluir los datos que el cliente ha solicitado.
Métodos de petición
Un pedido HTTP usando telnet. La petición
(request), cabeceras de respuesta (response headers) y el cuerpo de la
respuesta (response body) están resaltados.
HTTP define una serie predefinida de métodos de petición (algunas
veces denominados "verbos", aunque este término no está presente en
las especificaciones) para indicar la acción que se desea realizar sobre el
recurso identificado. Que este recurso sea preexistente (datos ya
almacenados) o se genere de forma dinámica depende de la
implementación del servidor. A menudo, el recurso corresponde a un
archivo o a la salida de un ejecutable que reside en el servidor.
La especificación de HTTP/1.0 define los métodos GET, HEAD y POST y
enumera los métodos PUT, DELETE, LINK Y UNLINK en una sección de
métodos adicionales. Sin embargo, la especificación HTTP/1.1 define
formalmente y añade cinco métodos nuevos: PUT, DELETE, CONNECT,
OPTIONS y TRACE. Cualquier cliente puede utilizar cualquier método y el
servidor se puede configurar para dar soporte a cualquier combinación
de métodos. En caso de que un método sea desconocido para un
intermediario, lo tratará como un método inseguro y no idempotente. No
hay límite para el número de métodos que se pueden definir, lo que
permite que se puedan especificar nuevos métodos sin afectar la
infraestructura anterior. Por ejemplo, WebDAV definió siete métodos
nuevos y el RFC 5789 especificó el método PATCH.
Los nombres de los métodos son sensibles a mayúsculas. Esto contrasta
con los nombres de los campos de las cabeceras HTTP, que no son
sensibles a mayúsculas.
Definiciones
1. Un método de petición es seguro si una petición con ese método
no tiene un efecto intencional en el servidor. En otras palabras, un
método es seguro si es de solo lectura. Sin embargo, un método
seguro puede tener efectos secundarios que el cliente no puede
ver, como añadir información de la petición a un archivo de
registro o realizar un cobro a una cuenta de publicidad.
2. Un método es idempotente si múltiples peticiones con ese
método tienen el mismo efecto que una sola petición. Los métodos
seguros son trivialmente idempotentes, ya que no deberían tener
efecto alguno en el servidor.
3. Un método es cacheable si se pueden almacenar las respuestas
para su futura reutilización.
Métodos estándar
Todos los servidores web de propósito general deben implementar al
menos los métodos GET y HEAD, mientras que el resto de métodos son
opcionales.[1]