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