HTTP Header之Content-Type

1. HTTP Header

HTTP 协议是建立在 TCP/IP 协议之上的应用层规范，以 ASCII 码传输。HTTP 规范把 HTTP 请求分为三个部分：状态行、请求头、消息主体。类似于下面这样：

<method><request-URL><version>

<headers>

<entity-body>

HTTP Header 包括通用头、请求头、响应头和实体头这四个部分。每个头域由一个头域的域名，冒号和域值组成。

通用头部，是客户端和服务器都可以使用的头部，可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能，如 Date 头部。
请求头部，是请求报文特有的，为服务器提供了一些额外信息，比如客户端希望接收什么类型的数据，如 Accept 头部。
响应头部，用于客户端提供信息，比如，客服端在与哪种类型的服务器进行交互，如 Server 头部。
实体头部，指的是用于应对实体主体部分的头部，比如，可以用实体头部来说明实体主体部分的数据类型，如 Content-Type 头部。

2. 文件请求和接口请求

通常的客户端与服务器的交互可以分为两类，一类是请求文件，html，js，css 等，另一类是接口数据请求。

但是在 HTTP 请求的过程中，这两类处理方法是一样的。

大多数浏览器限制 URL 长度在 2K 字节以内，而大多数服务最多处理 64K 大小的 URL。如果使用的是 GET 服务，在 body 里面传输数据，不同服务的处理方式也不同，有的可能会被处理，有的会被忽略。

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集成，配置好持续性集成，指定自动运行测试用例的时机。

5. 参考