那些年被忽略的——HTTP的实体（Entity）

• 这是我参与11月更文挑战的第5天，活动详情查看：2021最后一次更文挑战

• 如果不被请求方法和响应状态码所限制，请求和响应都可以传输实体。

• 实体包括实体头部和实体主体。

实体头部

• 实体都不定义了实体主体的元信息，或在无主体的情况下定义了请求资源的元信息。

entity-head= Allow | Content-Encoding|Content-Language|Content-Location|Content-MD5|Content-Range|Content-Type|Expires|Last-Modified|extension-header

• 扩展头部允许在不改变协议的前提下定义额外的试题头不，但不保证这些在接收端能被识别。未被识别的头部应当被接收者忽略。

实体主体

• 由HTTP请求或响应发送的实体主体（如果存在的话）的格式与编码方式应由实体的头部决定。
• 只有当消息主体存在时才存在。
• 实体主体是消息主题根据传输编码解码得到。

类型

• 消息包含主体时，主体的数据类型由实体头部的Content-Type和Content-Encoding决定。
• Content-Type指定了下层数据的媒体类型
• Content-Encoding可能被用来指定附加数据的内容编码，经常用于数据压缩，内容编码是请求资源的属性。
• 任一包含了实体主体的HTTP/1.1消息都应包括Content-type来定义实体主体的媒体类型。如果媒体类型没有被Content-Type定义，接收者会尝试猜测媒体类型，通过查看实体主体的内容或者通过查看URI制定资源的扩展名，如果媒体类型仍然不清楚，接收这会认为类型为"applicaition/octec-stream"

长度

• 消息的主体长度指的是消息主题在被用于传输编码前的长度。

总结

• 综合前面几篇文章关于请求、消息和主体，POST方法的消息主体在实体主体中，接收端会根据请求头中的Content-Type来获取媒体类型，从而解析数据。顺便可以列举一下这几个

  • application/x-form-uelencoded
    • 最常见的POST提交数据的方式，原生Form表单不设置enctype，默认的提交方式，提交的表单数据会转换为键值对并且按照key1=val1&key2=val2的方式编码
  • multipart/form-data
    • Form表单的enctype设置为multipart/form-data，会将表单的数据处理为一条信息，以标签为单元，用分隔符（boundary）分开。这种方式下的数据，可以是键值对，也可以上传文件。当上传的字段是文件时，会有Content-Type来说明文件类型。每部分都是以-boundary开始，后跟内容描述信息的一行，然后具体内容（字段、文本或者二进制）。消息主体以-boundary-标示结束
  • application/json
    • 告诉服务端消息主体是序列化后的JSON字符串。JSON格式支持比键值对更复杂的结构化的数据。除了低版本的IE浏览器其他各大浏览器都原生支持JSON.stringfy，服务端语言也都有处理JSON的函数，使用起来没有困难。
  • text/xml
    • xml用于传输和存储数据，提供统一的方法来描述和交换独立于应用的结构化数据。
  • applicaition/octec-stream
    • 二进制文件流
    • 在Postman里的binary可以模拟这种请求
    • 举个栗子：对于text文件类型，如果没有特定子类型，使用text/plain。再比如application/pdf，指定了MIME类型。当二进制文件没有特定或者已知的子类型，就会使用applicaition/octec-stream。
    • 对于这类请求，只能提交二进制，并且只能提交一个二进制。如果是文件的话，只能提交一个文件。

• 欢迎点赞、评论。