MTODOS HTTP

PROGRAMACIN WEB

INTEGRANTES:
ADRIANA ARENAS TORRES
YOUNG REYES EDGAR
DE LA CRUZ CAMBRANO JUAN MANUEL
 MTODOS DE PETICIN

HTTPdefine8mtodosqueindicalaaccinquedeseaque
seefectesobreelrecursoidentificado.Loqueesterecurso
representa,silosdatospre-existentesodatosquesegeneran
deformadinmica,dependedelaaplicacindelservidor.A
menudo,elrecursocorrespondeaunarchivoolasalidadeun

ejecutablequeresidenenelservidor.
 HEAD
Pide una respuesta idntica a la que
correspondera a una peticin GET, pero sin el
cuerpo de la respuesta. Esto es til para la
recuperacin de meta-informacin escrita en
los encabezados de respuesta, sin tener que
transportar todo el contenido.

Funciona como el GET, pero sin que el

servidor devuelva el cuerpo del mensaje. Es
decir, slo se devuelve la informacin de

cabecera.
 GET
Pide una representacin del recurso especificado. Por seguridad no debera ser
usado por aplicaciones que causen efectos ya que transmite informacin a travs de
la URI agregando parmetros a la URL.

Ejemplo:

GET /images/logo.png HTTP/1.1 obtiene un recurso llamado
logo.png
Ejemplo con parmetros:
/index.php?page=main&lang=es
Devuelve el recurso identificado en la URL pedida.
 POST
Somete los datos a que sean procesados Indica al servidor que se prepare
para el recurso identificado. Los datos se para recibir informacin del
incluirn en el cuerpo de la peticin. cliente. Suele usarse para enviar
Esto puede resultar en la creacin de un
nuevo recurso o de las actualizaciones de informacin desde formularios.
los recursos existentes o ambas cosas.
 PUT
Sube, carga o realiza un upload de un recurso especificado (archivo), es
el camino ms eficiente para subir archivos a un servidor, esto es porque en
POST utiliza un mensaje multiparte y el mensaje es decodificado por el
servidor. En contraste, el mtodo PUT te permite escribir un archivo en una
conexin socket establecida con el servidor.

La desventaja del mtodo PUT es Ejemplo:

que los servidores de hosting PUT /path/filename.html HTTP/1.1
compartido no lo tienen
habilitado.
 DELETE

Borra el recurso especificado.

Solicita al servidor que borre el recurso

identificado con el URL.
 TRACE
Este mtodo solicita al servidor que enve de vuelta en un mensaje de respuesta, en
la seccin del cuerpo de entidad, toda la data que reciba del mensaje de solicitud. Se
utiliza con fines de comprobacin y diagnostico.

Inicia un ciclo de mensajes de peticin. Se usa para depuracin y

permite al cliente ver lo que el servidor recibe en el otro lado.

 OPTIONS
Devuelve los mtodos HTTP que el servidor soporta para un URL
especfico. Esto puede ser utilizado para comprobar la funcionalidad de un
servidor web mediante peticin en lugar de un recurso especfico.

Pide informacin sobre las caractersticas de

comunicacin proporcionadas por el servidor. Le
permite al cliente negociar los parmetros de
comunicacin.
 URI
Versin El mtodo le indica al servidor que
hacer con el URI , por ltimo la versin
simplemente indica el nmero de versin del
protocolo que el cliente entiende.

Una peticin habitual utiliza el mtodo GET para pedirle al

servidor que devuelva el URI solicitado:

GET /index.html HTTP/1.0

 CONNECT

Este mtodo se reserva para uso con proxys.

Permitir que un proxy pueda dinmicamente
convertirse en un tnel. Por ejemplo para
comunicaciones con SSL.
 MTODO URI
El mtodo le indica al servidor que hacer con el URI , por ltimo
la versin simplemente indica el nmero de versin del protocolo
que el cliente entiende. Una peticin habitual utiliza el mtodo
GET para pedirle al servidor que devuelva el URI solicitado:

GET /index.html HTTP/1.0

 MTODOS DE SEGURIDAD
Ejecutores deben ser conscientes de que el software representa al usuario en sus
interacciones a travs de Internet, y debe tener cuidado para permitir al usuario
estar al tanto de las acciones que podra adoptar medidas que puedan tener una
importancia inesperada a s mismos a otros.

En particular, la convencin se ha establecido que los mtodos GET y CABEZA NO

DEBE tener la importancia de tomar una accin distinta a la recuperacin. Estos mtodos
deben ser considerados "seguros". Esto permite que los agentes de usuario para
representar a otros mtodos, como POST, PUT y DELETE, de una manera especial, para
que el usuario sea consciente del hecho de que una accin que posiblemente sean
inseguras se solicita.
 MTODOS IDEMPOTENTES
Los mtodos tambin pueden tener la caracterstica de
"idempotencia" en que (aparte de las cuestiones de error o
de vencimiento) los efectos secundarios de N> 0 peticiones
idnticas es el mismo que para una sola peticin. Los
mtodos GET, HEAD, PUT y compartir SUPR esta propiedad.
Adems, las opciones de mtodos y TRACE no debe tener
efectos secundarios, por lo que son inherentemente
idempotente.
 Sin embargo, es posible que una secuencia de varias
solicitudes no es idempotente, aunque todos los
mtodos de ejecucin en ese orden son idempotentes.
(Una secuencia es idempotente si una sola ejecucin
de toda la secuencia siempre produce un resultado
que no se cambia por un reexecution de todos o parte
de esa secuencia.) Por ejemplo, una secuencia no es
idempotente si su resultado depende de una valor que
luego es modificada en la misma secuencia.
Una secuencia que no tiene efectos
secundarios es idempotente, por
definicin (siempre que no haya
operaciones simultneas se estn
ejecutando en el mismo conjunto de
recursos).