Conceptos de ASP.Net : Métodos HTTP

• Métodos HTTP

Los metodos que forman parte del Hyper-Text Transfer Protocol (HTTP) son 6 :

1. OPTIONS:  Este método representa una petición (request) de información de las opciones de comunicación disponibles en la cadena request/response identificada por el Request-URI. Este método permite al cliente determinar las opciones y/o requerimientos asociados a un recurso, o las capacidades del servidor.
2. GET:   El método GET retorna cualquier información (en forma de una entidad) que esté identificada por el Request-URI. Si el Request-URI se refiere a un proceso de producción de datos, entonces los datos producidos serán retornados como una entidad en la respuesta y no el texto del proceso, a menos que el texto sea la salida del proceso.
3. HEAD:   El método HEAD es idéntico al método GET, excepto que el servidor NO DEBE retornar un message-body en la respuesta. La metainformación contenida en las cabezeras (headers) HTTP en respuesta a una petición HEAD DEBE ser idéntica a la información enviada en respuesta a una petición GET. Este método puede ser utilizado para obtener metainformación sobre la entidad implicada en la petición sin transferir la entidad como tal.
4. POST:   El método POST es utilizado para pedir que el servidor de origen acepte la entidad adjunta en la petición como un nuevo subordinado del recurso identificado por el Request-URI en la Línea de Petición (Request-Line). El POST está diseñado como un método uniforme para cubrir las siguientes functiones:
   • Anotación de recursos existentes
   • Enviar un mensaje a un boletín, grupo de noticias, lista de correo o un un grupo similar de artículos
   • Proveer un bloque de datos, como el resultado de enviar un formulario, a un proceso manejador de datos
   • Extender una base de datos a través de una operacción de anexado (append)
   La función real realizado por el método POST se determina por el servidor y es por lo general depende de la Request-URI. La entidad publicado está subordinada a la URI de la misma manera que un archivo está subordinado a un directorio que lo contiene, un artículo de noticias está subordinado a un grupo de noticias al cual está publicado, o un registro está subordinada a una base de datos. La acción realizada por el método POST podría no dar lugar a un recurso que pueda ser identificado por un URI. En este caso, o bien 200 (OK) o 204 (Sin contenido) es el estado de la respuesta apropiada, en función de si la respuesta incluye una entidad que describe el resultado o no. Si el recurso se ha creado en el servidor de origen, la respuesta debe ser 201 (Created) y contener una entidad que describa el estado de la solicitud y se refiera al nuevo recurso, y una cabecera Location.
5. PUT:   El método PUT pide que la entidad adjunta sea almacenado bajo el Request-URI suministrado. Si la Request-URI se refiere a un recurso ya existente, la entidad adjunta DEBE ser considerada como una versión modificada de la que reside en el servidor de origen. Si el Request-URI no apunta a un recurso existente, y el URI puede ser definido como un nuevo recurso por el agente de usuario que solicita, el servidor de origen puede crear el recurso con el URI. Si se crea un nuevo recurso, el servidor de origen debe informar al agente de usuario a través de la Respuesta 201 (Created). Si se modifica un recurso existente, SE DEBE enviar una respuesta ya sea con el código 200 (OK) o 204 (No Content) para indicar la finalización con éxito de la solicitud. Si el recurso no se puede crear o modificar con el Request-URI, se debe dar una respuesta de error apropiado que refleje la naturaleza del problema. El destinatario de la entidad no debe ignorar cualquier encabezado Content-* (por ejemplo, Content-Range) que no entienda o implemente y DEBE devolver una respuesta 501 (Not Implemented) en esos casos.
6. DELETE:   El método DELETE pide que el servidor de origen elimine el recurso identificado por el Request-URI. Este método puede ser anulado por interveción humano (u otros medios) en el servidor de origen. No se le puede asegurar al cliente que la operación se haya llevado a cabo, aún si código de estado retornado por el servidor de origen indica que la acción ha sido completada sastifactoriamente. Una respuesta sastifactoria DEBE ser 200 (OK) si la respuesta incluye una entidad describiendo el estado, 202 (Accepted) si la acción todavía no ha sido promulgada, o 204 (No content) si la acción ha sido promulgada pero la respuesta no incluye una entidad.
7. TRACE: &nbps; El método TRACE es utilizado para invocar un loop-back remoto desde la capa de aplicación del mensaje de petición. El recipiente final de la petición DEBE reflejar el mensaje devuelto al cliente como el cuerpo de entidad de una respuesta 200 (OK).El método TRACE permite al cliente ver que está siendo recibido al otro lado de la cadena de petición y usar esos datos para pruebas o diagnóstico de información.
8. CONNECT: Este método se para conectarse a un proxy que puede convertirse dinámicamente en un túnel (por ejemplo, SSL Tunneling).