metodos - peticiones http java
¿Cómo se envían los parámetros en una solicitud HTTP POST? (8)
Algunos de los servicios web requieren que coloque datos de solicitud y metadatos por separado. Por ejemplo, una función remota puede esperar que la cadena de metadatos firmada se incluya en un URI, mientras que los datos se publican en un cuerpo HTTP.
La solicitud POST puede verse semánticamente así:
POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1
Content-Type: text/tab-separated-values; charset=iso-8859-1
Content-Length: []
Host: webservices.domain.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)
name id
John G12N
Sarah J87M
Bob N33Y
Este enfoque combina lógicamente QueryString y Body-Post utilizando un único tipo de Content-Type que es una "instrucción de análisis" para un servidor web.
Tenga en cuenta: HTTP / 1.1 se ajusta con el #32 (espacio) a la izquierda y con el #10 (alimentación de línea) a la derecha.
En una solicitud HTTP GET , los parámetros se envían como una cadena de consulta :
http://example.com/page?parameter=value&also=another
En una solicitud HTTP POST , los parámetros no se envían junto con el URI.
¿Dónde están los valores? En el encabezado de la solicitud? En el cuerpo de la solicitud? Cómo se ve?
El contenido se pone después de los encabezados HTTP. El formato de un HTTP POST es tener los encabezados HTTP, seguido de una línea en blanco, seguido del cuerpo de la solicitud. Las variables POST se almacenan como pares clave-valor en el cuerpo.
Puede ver esto en el contenido sin formato de una publicación HTTP, que se muestra a continuación:
POST /path/script.cgi HTTP/1.0
From: [email protected]
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
home=Cosby&favorite+flavor=flies
Puede ver esto utilizando una herramienta como Fiddler , que puede usar para ver las cargas útiles de respuesta y solicitud HTTP sin procesar que se envían a través del cable.
El tipo de medio predeterminado en una solicitud POST es application/x-www-form-urlencoded . Este es un formato para codificar pares clave-valor. Las claves pueden ser duplicadas. Cada par clave-valor está separado por un carácter & , y cada clave está separada de su valor por un carácter = .
Por ejemplo:
Name: John Smith
Grade: 19
Se codifica como:
Name=John+Smith&Grade=19
Esto se coloca en el cuerpo de la solicitud después de los encabezados HTTP.
En primer lugar, vamos a diferenciar entre GET y POST
Obtener: ¿ Es la solicitud HTTP predeterminada que se realiza al servidor y se utiliza para recuperar los datos del servidor y la cadena de consulta que viene después ? en un URI se utiliza para recuperar un recurso único.
este es el formato
GET /someweb.asp?data=value HTTP/1.0
aquí data=value es el valor de cadena de consulta pasado.
POST: se utiliza para enviar datos al servidor de forma segura, por lo que cualquier cosa que sea necesaria, este es el formato de una solicitud POST
POST /somweb.aspHTTP/1.0
Host: localhost
Content-Type: application/x-www-form-urlencoded //you can put any format here
Content-Length: 11 //it depends
Name= somename
¿Por qué POST sobre GET?
En GET el valor que se envía a los servidores generalmente se anexa a la URL base en la cadena de consulta. Esto hace que sus datos puedan ser pirateados (esto fue un problema en los días en que Facebook expuso sus credenciales). utilizado para enviar datos al servidor que utilizó el Request Body para enviar sus datos al servidor, que es más seguro porque oculta sus datos y obtiene sus datos de los campos, calcula la longitud de los mismos y los agrega al header para content-length y ningún dato importante se adjunta directamente a la URL
ahora que su solicitud está segura, cualquier valor que se envíe al servidor puede enviarse en el Request Body la Request Body como su nombre indica, contendrá los datos que el usuario desea enviar (y se envía en el formato URL Encoded ) y los Request Headers la Request Headers mantenga la Solicitud segura comparando los valores en el Request Body con los Request Headers
Puede utilizar la sección de red de Google Developer Tools para ver información básica sobre cómo se realizan las solicitudes a los servidores.
y siempre puede agregar más valores en sus Request Headers como Cache-Control , Origin , Accept .
Los valores de formulario en HTTP POST se envían en el cuerpo de la solicitud, en el mismo formato que la cadena de consulta.
Para obtener más información, consulte la spec .
Los valores se envían en el cuerpo de la solicitud, en el formato que especifica el tipo de contenido.
Por lo general, el tipo de contenido es application/x-www-form-urlencoded , por lo que el cuerpo de la solicitud utiliza el mismo formato que la cadena de consulta:
parameter=value&also=another
Cuando utiliza una carga de archivo en el formulario, en su lugar, utiliza la codificación multipart/form-data , que tiene un formato diferente. Es más complicado, pero generalmente no es necesario que te importe cómo se ve, así que no mostraré un ejemplo, pero puede ser bueno saber que existe.
No puede escribirlo directamente en la barra de URL del navegador.
Puede ver cómo se envían los datos de POST a Internet con encabezados HTTP en vivo, por ejemplo. El resultado será algo así.
http://127.0.0.1/pass.php
POST /pass.php HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://127.0.0.1/pass.php
Cookie: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
username=zurfyx&pass=password
En donde dice
Content-Length: 30
username=zurfyx&pass=password
serán los valores posteriores.
Respuesta corta: en las solicitudes POST, los valores se envían en el "cuerpo" de la solicitud. Con los formularios web, lo más probable es que se envíen con un tipo de medio de application/x-www-form-urlencoded o multipart/form-data . Los lenguajes de programación o marcos que han sido diseñados para manejar solicitudes web generalmente hacen "The Right Thing ™" con dichas solicitudes y le brindan un acceso fácil a los valores fácilmente decodificados (como $_REQUEST o $_POST en PHP, o cgi.FieldStorage() , flask.request.form en Python).
Ahora vamos a divagar un poco, lo que puede ayudar a entender la diferencia;)
La diferencia entre las solicitudes GET y POST es en gran medida semántica. También se "utilizan" de manera diferente, lo que explica la diferencia en cómo se pasan los valores.
GET ( sección RFC correspondiente )
Al ejecutar una solicitud GET , le pide al servidor una o un conjunto de entidades. Para permitir que el cliente filtre el resultado, puede usar la llamada "cadena de consulta" de la URL. La cadena de consulta es la parte después de la ? . Esto es parte de la sintaxis URI .
Por lo tanto, desde el punto de vista del código de su aplicación (la parte que recibe la solicitud), deberá inspeccionar la parte de consulta de URI para obtener acceso a estos valores.
Tenga en cuenta que las claves y los valores son parte de la URI. Los navegadores pueden imponer un límite en la longitud de URI. El estándar HTTP establece que no hay límite. Pero en el momento de escribir este artículo, la mayoría de los navegadores limitan los URI (no tengo valores específicos). GET solicitudes GET nunca deben usarse para enviar nueva información al servidor. Especialmente no documentos de mayor tamaño. Ahí es donde debes usar POST o PUT .
POST ( sección RFC correspondiente )
Al ejecutar una solicitud POST , el cliente realmente envía un nuevo documento al host remoto. Por lo tanto, una cadena de consulta no tiene sentido (semánticamente). Es por eso que no tiene acceso a ellos en el código de su aplicación.
POST es un poco más complejo (y mucho más flexible):
Al recibir una solicitud POST, siempre debe esperar una "carga útil" o, en términos de HTTP: un cuerpo del mensaje . El cuerpo del mensaje en sí mismo es bastante inútil, ya que no existe un formato estándar (por lo que puedo decir. ¿Tal vez la aplicación / octet-stream?). El formato del cuerpo está definido por el encabezado Content-Type . Cuando se utiliza un elemento de FORM HTML con el method="POST" , esto suele ser application/x-www-form-urlencoded . Otro tipo muy común es multipart/form-data si usas cargas de archivos. Pero puede ser cualquier cosa , desde text/plain , sobre application/json o incluso una application/octet-stream personalizada application/octet-stream .
En cualquier caso, si una solicitud POST se realiza con un tipo de Content-Type que no puede ser manejado por la aplicación, debe devolver un código de estado 415 .
La mayoría de los lenguajes de programación (y / o marcos web) ofrecen una forma de de / codificar el cuerpo del mensaje de / a los tipos más comunes (como application/x-www-form-urlencoded , multipart/form-data o application/json ) . Así que eso es fácil. Los tipos personalizados requieren potencialmente un poco más de trabajo.
Usando un documento codificado en un formulario HTML estándar como ejemplo, la aplicación debe realizar los siguientes pasos:
- Lee el campo
Content-Type - Si el valor no es uno de los tipos de medios admitidos, devuelva una respuesta con un código de estado
415 - de lo contrario, decodifique los valores del cuerpo del mensaje.
Una vez más, los lenguajes como PHP, o marcos web para otros lenguajes populares probablemente manejarán esto por usted. La excepción a esto es el error 415 . Ningún marco puede predecir qué tipo de contenido elige o no admite su aplicación. Esto depende de ti.
PUT ( sección RFC correspondiente )
Una solicitud PUT se maneja prácticamente de la misma manera que una solicitud POST . La gran diferencia es que se supone que una solicitud POST debe permitir que el servidor decida cómo (y en todo caso) crear un nuevo recurso. Históricamente (a partir de la ahora obsoleta RFC2616 se trataba de crear un nuevo recurso como "subordinado" (hijo) de la URI a la que se envió la solicitud).
Se supone que una solicitud PUT en contraste "deposita" un recurso exactamente en ese URI y con exactamente ese contenido. Ni mas ni menos. La idea es que el cliente es responsable de crear el recurso completo antes de "PONER". El servidor debe aceptarlo como está en la URL dada.
Como consecuencia, una solicitud POST generalmente no se usa para reemplazar un recurso existente. Una solicitud PUT puede hacer tanto crear como reemplazar.
Nota al margen
También hay " parámetros de ruta " que pueden usarse para enviar datos adicionales al control remoto, pero son tan poco comunes que no voy a entrar en demasiados detalles aquí. Pero, para referencia, aquí hay un extracto de la RFC:
Aparte de los segmentos de puntos en las rutas jerárquicas, un segmento de ruta se considera opaco por la sintaxis genérica. Las aplicaciones que producen URI a menudo usan los caracteres reservados permitidos en un segmento para delimitar subcomponentes específicos del esquema o del desreferenciador específico. Por ejemplo, los caracteres reservados de punto y coma (";") y iguales ("=") a menudo se usan para delimitar parámetros y valores de parámetros aplicables a ese segmento. El carácter reservado con coma (",") se utiliza a menudo para fines similares. Por ejemplo, un productor de URI podría usar un segmento como "nombre; v = 1.1" para indicar una referencia a la versión 1.1 de "nombre", mientras que otro podría usar un segmento como "nombre, 1.1" para indicar lo mismo. Los tipos de parámetros pueden definirse por semántica específica del esquema, pero en la mayoría de los casos la sintaxis de un parámetro es específica a la implementación del algoritmo de desreferenciación de URI.