Mi lista de blogs

miércoles, 2 de febrero de 2011

MÉTODOS HTTP

MÉTODOS DE PETICION

HTTP define 8 métodos (algunas veces referido como "verbos") que indica la acción que desea que se efectúe sobre el recurso identificado. Lo que este recurso representa, si los datos pre-existentes o datos que se generan de forma dinámica, depende de la aplicación del servidor. A menudo, el recurso corresponde a un archivo o la salida de un ejecutable que residen en el servidor.

HEAD
Pide una respuesta idéntica a la que correspondería a una petición GET, pero sin el cuerpo de la respuesta. Esto es útil para la recuperación de meta-información escrita en los encabezados de respuesta, sin tener que transportar todo el contenido.
GET
Pide una representación del recurso especificado. Por seguridad no debería ser usado por aplicaciones que causen efectos ya que transmite información a través de la URI agregando parámetros a la URL.
Ejemplo:

GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png

Ejemplo con parámetros:
/index.php?page=main&lang=es

POST
Somete los datos a que sean procesados para el recurso identificado. Los datos se incluirán en el cuerpo de la petición. Esto puede resultar en la creación de un nuevo recurso o de las actualizaciones de los recursos existentes o ambas cosas.
PUT
Sube, carga o realiza un upload de un recurso especificado (archivo), es el camino más 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 método PUT te permite escribir un archivo en una conexión socket establecida con el servidor.
La desventaja del método PUT es que los servidores de hosting compartido no lo tienen habilitado.
Ejemplo:
PUT /path/filename.html HTTP/1.1

DELETE
Borra el recurso especificado.

TRACE
Este método solicita al servidor que envíe de vuelta en un mensaje de respuesta, en la sección del cuerpo de entidad, toda la data que reciba del mensaje de solicitud. Se utiliza con fines de comprobación y diagnostico.


OPTIONS
Devuelve los métodos HTTP que el servidor soporta para un URL específico. Esto puede ser utilizado para comprobar la funcionalidad de un servidor web mediante petición en lugar de un recurso específico

 
MÉTODO  URI  

El método le indica al servidor que hacer con el URI , por último la versión simplemente indica el número de versión del protocolo que el cliente entiende. Una petición habitual utiliza el método GET para pedirle al servidor que devuelva el URI solicitado:
GET /index.html HTTP/1.0




MÉTODOS DE SEGURIDAD



Ejecutores deben ser conscientes de que el software representa al usuario en sus interacciones a través de Internet, y debe tener cuidado para permitir al usuario estar al tanto de las acciones que podría adoptar medidas que puedan tener una importancia inesperada a sí mismos oa otros.

En particular, la convención se ha establecido que los métodos GET y CABEZA NO DEBE tener la importancia de tomar una acción distinta a la recuperación. Estos métodos deben ser considerados "seguros". Esto permite que los agentes de usuario para representar a otros métodos, como POST, PUT y DELETE, de una manera especial, para que el usuario sea consciente del hecho de que una acción que posiblemente sean inseguras se solicita.

Naturalmente, no es posible garantizar que el servidor no genera efectos secundarios como resultado de realizar una solicitud GET, de hecho, algunos recursos dinámicos en cuenta que una característica. La distinción importante aquí es que el usuario no solicitó los efectos secundarios, por lo tanto, no pueden ser considerados responsables de ellos.


MÉTODOS IDEMPOTENTES


Los métodos también pueden tener la característica de "idempotencia" en que (aparte de las cuestiones de error o de vencimiento) los efectos secundarios de N> 0 peticiones idénticas es el mismo que para una sola petición. Los métodos GET, HEAD, PUT y compartir SUPR esta propiedad. Además, las opciones de métodos 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 métodos de ejecución en ese orden son idempotentes. (Una secuencia es idempotente si una sola ejecución 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 definición (siempre que no haya operaciones simultáneas se están ejecutando en el mismo conjunto de recursos). 

 

No hay comentarios:

Publicar un comentario