Estoy utilizando la extensión Postman Chrome para probar un servicio web. Hay tres opciones disponibles para la entrada de datos. Supongo que la raw es para enviar JSON. ¿Cuál es la diferencia entre las otras dos, form-data y x-www-form-urlencoded?
Estos son diferentes tipos de contenido de formulario definidos por el W3C. Si desea enviar datos de texto simple/ ASCII, entonces x-www-form-urlencoded funcionará. Este es el valor por defecto.
Pero si tiene que enviar texto no ASCII o datos binarios grandes, el form-data es para eso.
Puedes usar Raw si quieres enviar texto plano o JSON o cualquier otro tipo de cadena. Como su nombre indica, Postman envía sus datos de cadena sin procesar tal y como son, sin modificaciones. El tipo de datos que está enviando puede establecerse utilizando la cabecera content-type del menú desplegable.
Binario se puede utilizar cuando se desea adjuntar datos no textuales a la solicitud, por ejemplo, un archivo de vídeo/audio, imágenes o cualquier otro archivo de datos binarios.
Consulte este enlace para obtener más información: Formularios en documentos HTML
Esto lo explica mejor: Postman docs
Cuerpo de la solicitud
Mientras construyes peticiones, estarás tratando mucho con el editor del cuerpo de la petición. Postman te permite enviar casi cualquier tipo de petición HTTP (Si no puedes enviar algo, ¡háznoslo saber!). El editor del cuerpo está dividido en 4 áreas y tiene diferentes controles dependiendo del tipo de cuerpo.
Datos del formulario
strike>multipart/form-data es la codificación por defecto que utiliza un formulario web para transferir datos. Esto simula el llenado de un formulario en un sitio web, y su envío. El editor de datos del formulario le permite establecer pares clave/valor (utilizando el editor clave-valor) para sus datos. También puede adjuntar archivos a una clave. Tenga en cuenta que, debido a las restricciones de la especificación HTML5, los archivos no se almacenan en el historial ni en las colecciones. Tendrás que volver a seleccionar el archivo en el momento de enviar una solicitud.
urlencoded
Esta codificación es la misma que la utilizada en los parámetros de la URL. Sólo tienes que introducir los pares clave/valor y Postman codificará las claves y los valores correctamente. Tenga en cuenta que no puede subir archivos a través de este modo de codificación. Puede haber alguna confusión entre form-data y urlencoded, así que asegúrate de comprobarlo primero con tu API.
raw
Una petición raw puede contener cualquier cosa. Postman no toca la cadena introducida en el editor raw, excepto para reemplazar las variables de entorno. Cualquier cosa que ponga en el área de texto se envía con la solicitud. El editor raw le permite establecer el tipo de formato junto con la cabecera correcta que debe enviar con el cuerpo raw. También puede establecer la cabecera Content-Type manualmente. Normalmente, usted estaría enviando datos XML o JSON aquí.
binario
Los datos binarios te permiten enviar cosas que no puedes introducir en Postman. Por ejemplo, archivos de imagen, audio o vídeo. También puede enviar archivos de texto. Como se mencionó anteriormente en la sección de datos de forma, tendría que volver a adjuntar un archivo si está cargando una solicitud a través de la historia o la colección.
ACTUALIZACIÓN
Como ha señalado VKK, las especificaciones del WHATWG dicen que urlencoded es el tipo de codificación por defecto para los formularios.
El valor no válido por defecto para estos atributos es el estado application/x-www-form-urlencoded. El valor no válido por defecto para el atributo enctype es también el estado application/x-www-form-urlencoded.
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 "multipart/form-data" y otros tipos de contenido, problemas de rendimiento, etc.
Consulte el apéndice para obtener información sobre cuestiones de seguridad de los formularios.
El tipo de contenido "application/x-www-form-urlencoded" es ineficaz para enviar grandes cantidades de datos binarios o texto que contenga caracteres no ASCII. El tipo de contenido "multipart/form-data" debe utilizarse para enviar formularios que contengan archivos, datos no ASCII y datos binarios.
El tipo de contenido "multipart/form-data" sigue las reglas de todos los flujos de datos MIME multiparte como se indica 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 procesador en el mismo orden en que aparecen los controles correspondientes en el flujo del documento. Los límites de las partes no deben aparecer en ninguno de los datos; la forma de hacerlo queda fuera del ámbito de esta especificación.
Como con todos los tipos MIME multiparte, cada parte tiene una cabecera opcional "Content-Type" que por defecto es "text/plain". Los agentes de usuario deben suministrar la cabecera "Content-Type", acompañada de un parámetro "charset".
application/x-www-form-urlencoded
Este es el tipo de contenido por defecto. Los formularios enviados con este tipo de contenido deben estar codificados de la siguiente manera:
Los nombres y valores de los controles se escapan. Los caracteres de espacio se sustituyen por +', y luego se escapan los caracteres reservados como se describe en [RFC1738], sección 2.2: Los caracteres no alfanuméricos se sustituyen por
%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'). Los nombres/valores de los controles se enumeran en el orden en que aparecen en el documento. El nombre se separa del valor mediante
=' y los pares nombre/valor se separan entre sí mediante `&'.
El cuerpo del mensaje HTTP que se envía al servidor es esencialmente una gigantesca cadena de consulta: los pares nombre/valor se separan con el signo ampersand (&), y los nombres se separan de los valores con el símbolo de igualdad (=). Un ejemplo de esto sería:
MyVariableOne=ValueOne&MyVariableTwo=ValueTwo
El tipo de contenido "application/x-www-form-urlencoded" es ineficaz para enviar grandes cantidades de datos binarios o de texto que contengan caracteres no ASCII. El tipo de contenido "multipart/form-data" debe utilizarse para enviar formularios que contengan archivos, datos no ASCII y datos binarios.