HTTP Header之Content-Type

1. HTTP Header

HTTP 協議是創建在 TCP/IP 協議之上的應用層規範，以 ASCII 碼傳輸。HTTP 規範把 HTTP 請求分爲三個部分：狀態行、請求頭、消息主體。相似於下面這樣：css

<method><request-URL><version>

<headers>

<entity-body>

HTTP Header 包括通用頭、請求頭、響應頭和實體頭這四個部分。每一個頭域由一個頭域的域名，冒號和域值組成。html

通用頭部，是客戶端和服務器均可以使用的頭部，能夠在客戶端、服務器和其餘應用程序之間提供一些很是有用的通用功能，如 Date 頭部。前端
請求頭部，是請求報文特有的，爲服務器提供了一些額外信息，好比客戶端但願接收什麼類型的數據，如 Accept 頭部。java
響應頭部，用於客戶端提供信息，好比，客服端在與哪一種類型的服務器進行交互，如 Server 頭部。chrome
實體頭部，指的是用於應對實體主體部分的頭部，好比，能夠用實體頭部來講明實體主體部分的數據類型，如 Content-Type 頭部。json

2. 文件請求和接口請求

一般的客戶端與服務器的交互能夠分爲兩類，一類是請求文件，html，js，css 等，另外一類是接口數據請求。api

可是在 HTTP 請求的過程當中，這兩類處理方法是同樣的。瀏覽器

大多數瀏覽器限制 URL 長度在 2K 字節之內，而大多數服務最多處理 64K 大小的 URL。若是使用的是 GET 服務，在 body 裏面傳輸數據，不一樣服務的處理方式也不一樣，有的可能會被處理，有的會被忽略。bash

HTTP 協議規定 POST 提交的數據必須放在消息主體（entity-body）中，但協議並無規定數據必須使用什麼編碼方式。服務器一般根據 HTTP Header 的實體頭部中的 Content-Type 字段來獲取請求中採用哪一種編碼，再對消息主體解析。

3. 幾種 Content-Type

Content-Type 屬性指定請求和響應的 HTTP 內容類型。

常見的Content-Type：

text/html，html 文件類型
text/plain，文本類型
text/css，css 文件類型
text/javascript，javascript 文件類型
application/x-www-form-urlencoded
multipart/form-data
application/json
application/xml

3.1 application/x-www-form-urlencoded

POST 提交的數據按照 key1=val1&key2=val2 的方式進行編碼，key 和 val 都進行 URL 轉碼。大部分服務端語言都對這種方式有很好的支持，瀏覽器的原生 form 表單就是按照這種方式提交。

Content-Type: application/x-www-form-urlencoded;charset=utf-8

title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

3.2 multipart/form-data

POST 提交的數據將被組織成 Key-Value 形式，用分隔符 boundary 處理成一條條消息。既可用於上傳文件，也能夠用於上傳參數。將 form 表單的 form 設置爲 multipart/form-data 時，按照這種方式提交。貌似在form表單上傳Binary文件的時候都必需要用這種格式。

Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA

------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text" title ------WebKitFormBoundaryrGKCBY7qhFd3TrwA Content-Disposition: form-data; name="file"; filename="chrome.png" Content-Type: image/png  PNG ... content of chrome.png ... ------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

3.3 raw

數據以純文本形式（text/json/xml/html）進行編碼，其中不含任何控件或格式字符。比較常見的 Content-Type 值有：application/json，text/xml ，text/plain等。

Content-Type: application/json;charset=utf-8

{"title":"test","sub":[1,2,3]}

Content-Type: text/xml

<?xml version="1.0"?> <methodCall> <methodName>examples.getStateName</methodName> <params> <param> <value><i4>41</i4></value> </param> </params> </methodCall>

4. Postman

做爲一個跨平臺的 API 測試工具，Postman 有 Win/Mac/Linux 客戶端，還有 Chrome 擴展程序。不管是前端、後臺仍是測試人員，均可以用 Postman 來測試接口，用起來很是方便。Postman 容許用戶發送任何類型的 HTTP 請求，例如 GET、POST、HEAD、PUT、DELETE 等，而且能夠容許任意的參數和 Headers。同時，支持不一樣的認證機制，包括 Basic Auth，Digest Auth，OAuth 1.0，OAuth 2.0，Hawk Authentication，AWS Signature 等，能夠自動格式化響應數據，高亮顯示。

除此，Postman 還提供以下功能。

Debugging and logs：能夠在控制檯對 Postman 的請求進行調試，特別是若是有 pre-request 或者 test script 時，使用控制檯能夠方便 debug。原生Postman 能夠經過 CMD/CTRL + ALT + C 打開控制檯。
Generate code snippets：將當前請求導出爲各類版本的請求代碼，好比 Python，js，curl等，方便用命令行測試。
Proxy：若是本機不能直接訪問服務端，能夠在Settings-Proxy-Using custom/system proxy設置代理。
Capturing HTTP requests：有時候用手機訪問服務端時，咱們可能須要藉助 fiddler 來查看HTTP請求。Postman 也能夠作相同的工做，只須要將Postman 做爲代理轉發HTTP請求便可。
Certificates：若是服務端要驗證客戶端證書，能夠在Settings-Certificates-Add Certificate配置證書。
pre-request script: 在發送請求以前執行的腳本，通常用來構建請求參數；
test script: 在獲取相應以後執行的腳本，通常用來作測試。不過須要注意，測試腳本運行在Sandbox環境，內置了許多JS庫支持，方便進行測試。
Sharing collections：能夠將Collection中的請求導出分享給其餘人；
Data formats：Postman能夠導出環境變量，甚至能夠將請求和環境變量等一塊兒打包爲一個Json，方便遷移全部的請求數據
Using environments in collection runs: 能夠指定一個 Environment，這樣collection中的請求可使用其中的變量；
Working with data files: 能夠導入一個Data File，裏面存放測試中用到的Data變量。能夠存放不少不一樣的Data變量，這樣迭代跑屢次Collection時，每次使用不一樣的數據；
Running multiple iterations: 能夠配置迭代的運行Collection中的請求，對接口的穩定性進行測試。此外配合Data files，也能夠對接口的正確性進行測試；
Building workflows：默認狀況下會順序執行Collection中的請求，不過能夠經過setNextRequest()來更改請求的執行流程。
Debugging a collection run: Collection中的請求執行後，會有可視化的執行結果展現，能夠方便進行調試，此外，也能夠經過控制檯來進行調試。
Sharing a collection run: 整個Collection Run也是能夠導出，能夠在其餘平臺進行運行；
Command line integration with Newman 導出Collection Run後，能夠在命令行使用 newman 運行。
Integration with Travis CI: 能夠將 newman 和 Travis CI集成，配置好持續性集成，指定自動運行測試用例的時機。