Cartero Chrome: ¿Cuál es la diferencia entre form-data, x-www-form-urlencoded y raw

222

Estoy usando la extensión Postman Chrome para probar un servicio web.

Hay tres opciones disponibles para la entrada de datos.

Supongo que rawes para enviar JSON.

¿Cuál es la diferencia entre los otros dos form-datay x-www-form-urlencoded?

Rohan
fuente
11
A partir de hoy, también hay una cuarta opción para publicar datos en la herramienta cartero binary.
RBT

Respuestas:

237

Estos son diferentes tipos de contenido de formulario definidos por W3C. Si desea enviar texto simple / datos ASCII, entonces x-www-form-urlencoded funcionará. Este es el valor predeterminado.

Pero si tiene que enviar texto no ASCII o datos binarios grandes, los datos del formulario son para eso.

Puede usar Raw si desea enviar texto sin formato o JSON o cualquier otro tipo de cadena. Como su nombre indica, Postman envía sus datos de cadena sin procesar tal como están sin modificaciones. El tipo de datos que está enviando se puede configurar utilizando el encabezado de tipo de contenido del menú desplegable.

Binario se puede usar cuando desea adjuntar datos no textuales a la solicitud, por ejemplo, un archivo de video / audio, imágenes o cualquier otro archivo de datos binarios.

Consulte este enlace para leer más: Formularios en documentos HTML

Basant Singh
fuente
¿Qué hay de binario?
RBT
¿Tengo un formulario que tiene 4 campos de texto y 1 campo de carga de archivos ahora, sugiérame qué opción (form-data o x-www-form-urlencoded) se utilizará para enviar estos 5 campos de valor en cartero? Gracias por adelantado.
Kamlesh
@Kamlesh, perdón por la respuesta tardía, el campo clave de los datos del formulario en Cartero tiene un menú desplegable donde puede seleccionar si es un campo de texto o archivo. Puede configurarlo en archivo y luego buscar un archivo para adjuntarlo al cuerpo. Espero que ayude.
Basant Singh
87

Esto explica mejor: documentos de cartero

Cuerpo de solicitud

Al construir solicitudes, se enfrentará mucho al editor del cuerpo de la solicitud. Postman le permite enviar casi cualquier tipo de solicitud HTTP (si no puede enviar algo, ¡háganoslo saber!). El editor de cuerpo está dividido en 4 áreas y tiene diferentes controles según el tipo de cuerpo.

datos de formulario

multipart / form-data es la codificación predeterminada que utiliza un formulario web para transferir datos. Esto simula llenar un formulario en un sitio web y enviarlo. El editor de datos de formulario le permite establecer pares clave / valor (utilizando el editor de clave-valor) para sus datos. También puede adjuntar archivos a una clave. Tenga en cuenta que debido a restricciones de la especificación HTML5, los archivos no se almacenan en el historial o las colecciones. Tendría que seleccionar el archivo nuevamente al momento de enviar una solicitud.

codificado por urlen

Esta codificación es la misma que la utilizada en los parámetros de URL. Solo necesita ingresar pares clave / valor y Postman codificará las claves y los valores correctamente. Tenga en cuenta que no puede cargar archivos a través de este modo de codificación. Puede haber cierta confusión entre los datos de formulario y los códigos urlen, así que asegúrese de consultar primero con su API.

crudo

Una solicitud sin procesar puede contener cualquier cosa. El cartero no toca la cadena ingresada en el editor sin formato, excepto que reemplaza las variables de entorno. Lo que pones en el área de texto se envía con la solicitud. El editor sin formato le permite establecer el tipo de formato junto con el encabezado correcto que debe enviar con el cuerpo sin formato. También puede configurar el encabezado Content-Type manualmente. Normalmente, estaría enviando datos XML o JSON aquí.

binario

Los datos binarios le permiten enviar cosas que no puede ingresar en Postman. Por ejemplo, archivos de imagen, audio o video. También puede enviar archivos de texto. Como se mencionó anteriormente en la sección de datos de formulario, tendría que volver a adjuntar un archivo si está cargando una solicitud a través del historial o la colección.

ACTUALIZAR

Como señaló VKK , la especificación WHATWG dice que urlencoded es el tipo de codificación predeterminado para formularios.

El valor predeterminado no válido para estos atributos es el estado application / x-www-form-urlencoded. El valor predeterminado que falta para el atributo enctype también es el estado application / x-www-form-urlencoded.

avck
fuente
55
El documento del cartero está equivocado. La especificación HTML5 de WHATWG disponible en html.spec.whatwg.org/multipage/… define claramente un valor predeterminado de "application / x-www-form-urlencoded" para el atributo enctype del elemento de formulario. En otras palabras, "application / x-www-form-urlencoded" es la codificación predeterminada (en términos HTTP, Content-Type) que un formulario web usa para transferir datos, no multipart / form-data. Para enviar una solicitud de publicación HTTP en el envío de formulario con un Tipo de contenido de datos multiparte / formulario, se debe especificar explícitamente esto como el valor de enctype.
VKK
Entonces, ¿cuál es la diferencia entre los datos de formulario (ingresados ​​con pares clave-valor en la IU del cartero) enviados con el Content-Type: application/jsonencabezado; y datos brutos ingresados ​​como json como {foo: bar}con el mismo Content-Type: application/jsonencabezado?
Iñigo
Con los datos de formulario como pares de valores clave, el tipo de contenido es datos de formulario multiparte incluso cuando especifica los encabezados y con el tipo de contenido sin formato será texto o lo que haya especificado en los encabezados.
avck
20

multipart / form-data

Nota. Consulte RFC2388 para obtener información adicional sobre la carga de archivos, incluidos los problemas de compatibilidad con versiones anteriores, la relación entre "multiparte / datos de formulario" y otros tipos de contenido, problemas de rendimiento, etc.

Consulte el apéndice para obtener información sobre problemas de seguridad para formularios.

El tipo de contenido "application / x-www-form-urlencoded" es ineficiente para enviar grandes cantidades de datos binarios o textos que contienen caracteres no ASCII. El tipo de contenido "multipart / form-data" debe usarse para enviar formularios que contienen archivos, datos no ASCII y datos binarios.

El tipo de contenido "multipart / form-data" sigue las reglas de todas las secuencias de datos MIME multiparte como se describe en RFC2045 . La definición de "multipart / form-data" está disponible en el registro [IANA].

Un mensaje "multipart / form-data" contiene una serie de partes, cada una de las cuales representa un control exitoso. Las partes se envían al agente de procesamiento en el mismo orden en que aparecen los controles correspondientes en la secuencia de documentos. Los límites de parte no deben ocurrir en ninguno de los datos; cómo se hace esto queda fuera del alcance de esta especificación.

Al igual que con todos los tipos MIME multiparte, cada parte tiene un encabezado opcional "Tipo de contenido" que por defecto es "texto / sin formato". Los agentes de usuario deben proporcionar el encabezado "Content-Type", acompañado de un parámetro "charset".

application / x-www-form-urlencoded

Este es el tipo de contenido predeterminado. Los formularios enviados con este tipo de contenido deben codificarse de la siguiente manera:

Los nombres y valores de control se escapan. Los caracteres de espacio se reemplazan por +', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by% HH ', un signo de porcentaje y dos dígitos hexadecimales que representan el código ASCII del carácter. Los saltos de línea se representan como pares "CR LF" (es decir, %0D%0A'). The control names/values are listed in the order they appear in the document. The name is separated from the value by= 'y los pares de nombre / valor están separados entre sí por `&'.

application/x-www-form-urlencodedEl cuerpo del mensaje HTTP enviado al servidor es esencialmente una cadena de consulta gigante: los pares de nombre / valor están separados por el signo y (&), y los nombres están separados de los valores por el símbolo de igual (=). Un ejemplo de esto sería:

MyVariableOne=ValueOne&MyVariableTwo=ValueTwo

El tipo de contenido "application / x-www-form-urlencoded" es ineficiente para enviar grandes cantidades de datos binarios o textos que contienen caracteres no ASCII. El tipo de contenido "multipart / form-data" debe usarse para enviar formularios que contienen archivos, datos no ASCII y datos binarios.

Mohideen bin Mohammed
fuente
15

Aquí hay algunos ejemplos suplementarios para ver el texto sin procesar que Postman pasa en la solicitud. Puede ver esto abriendo la consola Postman:

ingrese la descripción de la imagen aquí

datos de formulario

Encabezamiento

content-type: multipart/form-data; boundary=--------------------------590299136414163472038474

Cuerpo

key1=value1key2=value2

x-www-form-urlencoded

Encabezamiento

Content-Type: application/x-www-form-urlencoded

Cuerpo

key1=value1&key2=value2

Texto sin formato / sin formato

Encabezamiento

Content-Type: text/plain

Cuerpo

This is some text.

Raw json

Encabezamiento

Content-Type: application/json

Cuerpo

{"key1":"value1","key2":"value2"}
Suragch
fuente