J'utilise l'extension Postman Chrome pour tester un service Web.

Trois options sont disponibles pour la saisie de données.

Je suppose que rawc'est pour envoyer du JSON.

Quelle est la différence entre les deux autres form-dataet x-www-form-urlencoded?

Il s'agit de différents types de contenu de formulaire définis par le W3C. Si vous souhaitez envoyer des données texte / ASCII simples, alors x-www-form-urlencoded fonctionnera. C'est la valeur par défaut.

Mais si vous devez envoyer du texte non ASCII ou des données binaires volumineuses, les données de formulaire sont pour cela.

Vous pouvez utiliser Raw si vous souhaitez envoyer du texte brut ou du JSON ou tout autre type de chaîne. Comme son nom l'indique, Postman envoie vos données de chaîne brutes telles quelles sans modifications. Le type de données que vous envoyez peut être défini à l'aide de l'en-tête de type de contenu dans la liste déroulante.

Le binaire peut être utilisé lorsque vous souhaitez joindre des données non textuelles à la demande, par exemple un fichier vidéo / audio, des images ou tout autre fichier de données binaires.

Reportez-vous à ce lien pour en savoir plus: Formulaires dans les documents HTML

Cela explique mieux: les documents Postman

Organe de demande

Lors de la construction des demandes, vous auriez beaucoup à faire avec l'éditeur de corps de demande. Postman vous permet d'envoyer presque n'importe quel type de demande HTTP (si vous ne pouvez pas envoyer quelque chose, faites-le nous savoir!). L'éditeur de corps est divisé en 4 zones et dispose de différents contrôles selon le type de corps.

Données de formulaire

multipart / form-data est l'encodage par défaut utilisé par un formulaire Web pour transférer des données. Cela simule le remplissage d'un formulaire sur un site Web et sa soumission. L'éditeur de données de formulaire vous permet de définir des paires clé / valeur (à l'aide de l'éditeur de valeur-clé) pour vos données. Vous pouvez également joindre des fichiers à une clé. Veuillez noter qu'en raison des restrictions de la spécification HTML5, les fichiers ne sont pas stockés dans l'historique ou les collections. Vous devrez sélectionner à nouveau le fichier au moment de l'envoi d'une demande.

urlencoded

Cet encodage est le même que celui utilisé dans les paramètres d'URL. Il vous suffit de saisir des paires clé / valeur et Postman encodera correctement les clés et les valeurs. Notez que vous ne pouvez pas télécharger de fichiers via ce mode d'encodage. Il peut y avoir une certaine confusion entre les données de formulaire et celles encodées en url.

brut

Une requête brute peut contenir n'importe quoi. Postman ne touche pas la chaîne entrée dans l'éditeur brut, à l'exception du remplacement des variables d'environnement. Tout ce que vous mettez dans la zone de texte est envoyé avec la demande. L'éditeur brut vous permet de définir le type de mise en forme ainsi que l'en-tête correct que vous devez envoyer avec le corps brut. Vous pouvez également définir manuellement l'en-tête Content-Type. Normalement, vous enverriez des données XML ou JSON ici.

binaire

les données binaires vous permettent d'envoyer des choses que vous ne pouvez pas entrer dans Postman. Par exemple, des fichiers image, audio ou vidéo. Vous pouvez également envoyer des fichiers texte. Comme mentionné précédemment dans la section des données du formulaire, vous devrez rattacher un fichier si vous chargez une demande via l'historique ou la collection.

METTRE À JOUR

Comme l'a souligné VKK , la spécification WHATWG indique que l'urlencoded est le type de codage par défaut pour les formulaires.

La valeur non valide par défaut pour ces attributs est l'état application / x-www-form-urlencoded. La valeur manquante par défaut pour l'attribut enctype est également l'état application / x-www-form-urlencoded.

multipart / form-data

Remarque. Veuillez consulter la RFC2388 pour plus d'informations sur les téléchargements de fichiers, y compris les problèmes de compatibilité ascendante, la relation entre les "multipart / form-data" et d'autres types de contenu, les problèmes de performances, etc.

Veuillez consulter l'annexe pour plus d'informations sur les problèmes de sécurité des formulaires.

Le type de contenu "application / x-www-form-urlencoded" est inefficace pour envoyer de grandes quantités de données binaires ou de texte contenant des caractères non ASCII. Le type de contenu "multipart / form-data" doit être utilisé pour soumettre des formulaires contenant des fichiers, des données non ASCII et des données binaires.

Le type de contenu "multipart / form-data" suit les règles de tous les flux de données MIME multipart comme indiqué dans la RFC2045 . La définition de "multipart / form-data" est disponible dans le registre [IANA].

Un message "multipart / form-data" contient une série de parties, chacune représentant un contrôle réussi. Les pièces sont envoyées à l'agent de traitement dans le même ordre que les contrôles correspondants apparaissent dans le flux de documents. Les limites des pièces ne doivent apparaître dans aucune des données; comment cela est fait sort du cadre de cette spécification.

Comme avec tous les types MIME en plusieurs parties, chaque partie a un en-tête "Content-Type" facultatif qui est par défaut "text / plain". Les agents utilisateurs doivent fournir l'en-tête "Content-Type", accompagné d'un paramètre "charset".

application / x-www-form-urlencoded

Il s'agit du type de contenu par défaut. Les formulaires soumis avec ce type de contenu doivent être codés comme suit:

Les noms et valeurs de contrôle sont échappés. Les caractères d'espace sont remplacés par +', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by% HH ', un signe de pourcentage et deux chiffres hexadécimaux représentant le code ASCII du caractère. Les sauts de ligne sont représentés par des paires "CR LF" (c'est-à-dire que %0D%0A'). The control names/values are listed in the order they appear in the document. The name is separated from the value by= 'et les paires nom / valeur sont séparés les uns des autres par "&".

application/x-www-form-urlencodedle corps du message HTTP envoyé au serveur est essentiellement une chaîne de requête géante - les paires nom / valeur sont séparées par l'esperluette (&), et les noms sont séparés des valeurs par le symbole égal (=). Un exemple de ceci serait:

MyVariableOne=ValueOne&MyVariableTwo=ValueTwo

Le type de contenu "application / x-www-form-urlencoded" est inefficace pour envoyer de grandes quantités de données binaires ou de texte contenant des caractères non ASCII. Le type de contenu "multipart / form-data" doit être utilisé pour soumettre des formulaires contenant des fichiers, des données non ASCII et des données binaires.

Voici quelques exemples supplémentaires pour voir le texte brut que Postman transmet dans la demande. Vous pouvez le voir en ouvrant la console Postman:

Données de formulaire

Entête

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

Corps

key1=value1key2=value2

x-www-form-urlencoded

Entête

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

Corps

key1=value1&key2=value2

Texte brut / brut

Entête

Content-Type: text/plain

Corps

This is some text.

Json brut

Entête

Content-Type: application/json

Corps

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