WebサービスのテストにPostman Chrome拡張機能を使用しています。

データ入力には3つのオプションがあります。

rawJSONを送信するためのものだと思います。

他にどのような2つの違いはある、form-dataとx-www-form-urlencoded？

これらは、W3Cによって定義されたさまざまなフォームコンテンツタイプです。単純なテキスト/ ASCIIデータを送信する場合は、x-www-form-urlencodedが機能します。これがデフォルトです。

しかし、ASCII以外のテキストまたは大きなバイナリデータを送信する必要がある場合、フォームデータはそのためのものです。

プレーンテキスト、JSON、またはその他の種類の文字列を送信する場合は、Rawを使用できます。名前が示すように、Postmanは変更なしでそのままの文字列データを送信します。送信するデータのタイプは、ドロップダウンのcontent-typeヘッダーを使用して設定できます。

バイナリは、テキスト以外のデータ（ビデオ/オーディオファイル、画像、その他のバイナリデータファイルなど）をリクエストに添付する場合に使用できます。

詳細については、このリンクを参照してください： HTMLドキュメント内のフォーム

これはよりよく説明されます： Postman docs

リクエストボディ

リクエストを作成する際、リクエストボディエディターを頻繁に使用します。Postmanでは、ほぼすべての種類のHTTPリクエストを送信できます（何かを送信できない場合は、お知らせください！）。ボディエディタは4つの領域に分かれており、ボディタイプに応じてさまざまなコントロールがあります。

フォームデータ

multipart / form-dataは、Webフォームがデータの転送に使用するデフォルトのエンコーディングです。これは、Webサイトのフォームへの入力と送信をシミュレートします。フォームデータエディターでは、データのキーと値のペアを（キーと値のエディターを使用して）設定できます。キーにファイルを添付することもできます。HTML5仕様の制限により、ファイルは履歴や​​コレクションに保存されないことに注意してください。リクエストの送信時にファイルを再度選択する必要があります。

urlencoded

このエンコーディングは、URLパラメータで使用されるものと同じです。キーと値のペアを入力するだけで、Postmanがキーと値を適切にエンコードします。このエンコードモードではファイルをアップロードできないことに注意してください。form-dataとurlencodedの間には混乱があるかもしれませんので、最初にAPIを確認してください。

生

生のリクエストには何でも含めることができます。Postmanは、環境変数を置き換えることを除いて、生のエディターに入力された文字列に触れません。テキスト領域に入力したものはすべてリクエストとともに送信されます。未加工エディターでは、未加工の本文とともに送信する必要のある正しいヘッダーと共に、フォーマットタイプを設定できます。Content-Typeヘッダーを手動で設定することもできます。通常、ここではXMLまたはJSONデータを送信します。

バイナリ

バイナリデータを使用すると、Postmanで入力できないものを送信できます。たとえば、画像、音声、動画ファイル。テキストファイルも送信できます。フォームデータセクションで前述したように、履歴またはコレクションを介してリクエストをロードする場合は、ファイルを再アタッチする必要があります。

更新

VKKで指摘されているように、WHATWG仕様では、urlencodedがフォームのデフォルトのエンコーディングタイプであるとしています。

これらの属性の無効な値のデフォルトは、application / x-www-form-urlencoded状態です。enctype属性のデフォルトの欠落値は、application / x-www-form-urlencoded状態でもあります。

multipart / form-data

注意。下位互換性の問題、「multipart / form-data」と他のコンテンツタイプの関係、パフォーマンスの問題など、ファイルのアップロードに関する追加情報については、RFC2388を参照してください。

フォームのセキュリティ問題については、付録を参照してください。

コンテンツタイプ「application / x-www-form-urlencoded」は、非ASCII文字を含む大量のバイナリデータまたはテキストを送信する場合は非効率的です。コンテンツタイプ「multipart / form-data」は、ファイル、非ASCIIデータ、およびバイナリデータを含むフォームの送信に使用する必要があります。

コンテンツタイプ「multipart / form-data」は、RFC2045で概説されているすべてのマルチパートMIMEデータストリームのルールに従います。「multipart / form-data」の定義は、[IANA]レジストリで利用できます。

「multipart / form-data」メッセージには、一連のパーツが含まれ、それぞれが正常なコントロールを表します。パーツは、対応するコントロールがドキュメントストリームに表示されるのと同じ順序で処理エージェントに送信されます。パーツの境界はどのデータでも発生しないはずです。これがどのように行われるかは、この仕様の範囲外です。

すべてのマルチパートMIMEタイプと同様に、各パートにはオプションの「Content-Type」ヘッダーがあり、デフォルトは「text / plain」です。ユーザーエージェントは、「charset」パラメーターを伴う「Content-Type」ヘッダーを提供する必要があります。

application / x-www-form-urlencoded

これがデフォルトのコンテンツタイプです。このコンテンツタイプで送信されるフォームは、次のようにエンコードする必要があります。

コントロールの名前と値はエスケープされます。スペース文字は、+', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by％HH '、パーセント記号、および文字のASCIIコードを表す2つの16進数で置き換えられます。改行は「CR LF」のペアとして表されます（つまり、%0D%0A'). The control names/values are listed in the order they appear in the document. The name is separated from the value by= 'と名前/値のペアは `＆'で互いに分離されます。

application/x-www-form-urlencodedサーバーに送信されるHTTPメッセージの本文は、基本的に1つの巨大なクエリ文字列です。名前と値のペアはアンパサンド（＆）で区切られ、名前は等号（=）で値から区切られます。この例は次のとおりです。

MyVariableOne=ValueOne&MyVariableTwo=ValueTwo

コンテンツタイプ「アプリケーション/ x-www-form-urlencodedでは、」非ASCII文字を含むバイナリデータまたはテキストを大量に送信するため非効率的です。コンテンツタイプ「multipart / form-data」は、ファイル、非ASCIIデータ、およびバイナリデータを含むフォームの送信に使用する必要があります。

以下は、Postmanがリクエストで渡す生のテキストを確認するための補足例です。これは、Postmanコンソールを開くと確認できます。

フォームデータ

ヘッダ

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

体

key1=value1key2=value2

x-www-form-urlencoded

ヘッダ

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

体

key1=value1&key2=value2

生のテキスト/プレーン

ヘッダ

Content-Type: text/plain

体

This is some text.

生のjson

ヘッダ

Content-Type: application/json

体

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