谁能向我描述一下HTTP实体到底是什么？
我正在阅读 HTTPClient 文档，但我不太明白这意味着什么？
【问题讨论】：
标签： http httpclient
HTTP entity 是 HTTP 请求或响应的主要部分，由 some of the headers 和正文（如果存在）组成。它似乎是没有请求或状态行的整个请求或响应（尽管只有certain header fields are considered part of the entity）。
为了说明；这是一个请求：
POST /foo HTTP/1.1 # Not part of the entity.
Content-Type: text/plain # ┬ The entity is from this line down...
Content-Length: 1234 # │
# │
Hello, World! ... # ┘
还有回应：
HTTP/1.1 200 OK # Not part of the entity.
Content-Length: 438 # ┬ The entity is from this line down...
Content-Type: text/plain # │
# │
Response body ... # ┘
【讨论】：
& 而不是&。不也是实体吗？有什么区别？
& 是 HTML character entity reference，与 HTTP 实体 不同。
这里有3个简单的案例：
案例 1。您在一个请求中上传 3 个文件。这 3 个文件是 3 个实体。他们每个人都有自己的Content-Type，以表明它是什么类型的文件。
案例 2。您正在查看一个网页。浏览器在后台下载了一个 html 文件作为实体。由于页面可以不断更新，您以后可能会得到一个完全不同的实体。
案例 3。您有一个 304 Not Modified。没有实体被转移。
总之，Entity 是 http 消息中的可选负载（请求或响应），因此它是 Entity 和留言。
一些适用于Message 的标头字段如Transfer-Encoding 描述了如何在中介之间传输消息，因此可以由请求/响应链上的任何应用程序添加或删除（hop-by-hop headers）。相比之下，Entity 应用的那些头部字段是一些属性，描述了实体的大小、类型、压缩算法等......
进一步阅读，引用 RFC 2616 第 1.4、4.5 和 4.3 节：
request chain --------------------------------------> UA -----v----- A -----v----- B -----v----- C -----v----- O <------------------------------------- response chain上图显示了用户代理和源服务器之间的三个中介（A、B 和 C）。穿越整个链的请求或响应消息将通过四个独立的连接。
有一些标头字段对请求和响应消息具有普遍适用性，但不适用于正在传输的实体。这些标头字段仅适用于正在传输的消息。
必须使用传输编码来指示应用程序应用的任何传输编码，以确保消息的安全和正确传输。 Transfer-Encoding 是消息的属性，而不是实体的属性，因此可以由请求/响应链中的任何应用程序添加或删除。
message-body = Transfer-Encoding( Content-Encoding(entity-body) )
其中Transfer-Encoding 可能是“chunked”，表示如何传输消息，Content-Encoding 可能是“gzip”，表示如何压缩实体。
【讨论】：
它是一个代表请求或响应有效负载的抽象。 JavaDoc 明确其用途和各种实体类型。
【讨论】：
HTTP 是一种在通过网络从远程机器访问信息时遵守的协议。通常网络是互联网，远程机器是服务器。
当你向 A 询问 B 的信息时，你给了他一个信息。 （要求）。 B 人回复您（响应）。请求和响应是 HTTP 消息类型。
A 可以要求 B 做某事，而不是询问信息。比如说，A 想要 B 将文件存储在安全的位置。因此，A 将该文件（HTTP 实体）传递给 B 并要求他做某事（HTTP 消息）。在这种情况下，Person 正在传递一个“实体”。在 HTTP Entity 的上下文中，它是附加在消息中的有效负载。
希望这个类比有所帮助。
【讨论】：
正如@hawkeye-parker 在评论中所说，Entity 似乎已被弃用。创建search in this 2014 rfc，您将看到有关 XML 实体和消息体的信息，但没有关于 Http 实体的信息。
尽管如此，HttpClient 和 JaxRS 客户端都有 setEntity() 和 getEntity() 方法。
考虑到公认的答案，两个库都是错误的！ HttpClient.setEntity() 不会删除之前设置的标题。
【讨论】：
HttpEntity 是您将在请求中传递的内容（带有标头）以及您在响应中获得的内容。
对于获取请求，我们传递简单的字符串
HttpHeaders headers = new HttpHeaders();
headers.setAccept(Arrays.asList(MediaType.APPLICATION_JSON));
HttpEntity<String> entity = new HttpEntity<String>(headers);
对于 Post 我们将传递完整的实体类
public String createProducts(@RequestBody Product product) {
HttpHeaders headers = new HttpHeaders();
headers.setAccept(Arrays.asList(MediaType.APPLICATION_JSON));
HttpEntity<Product> entity = new HttpEntity<Product>(product,headers);
return restTemplate.exchange(
"http://localhost:8080/products", HttpMethod.POST, entity, String.class
).getBody();
}
【讨论】：
在我们在这里得到的好答案中，我认为值得一提的是直接来自RFC 2616 (Hypertext Transfer Protocol - HTTP/1.1)：
实体
请求和响应消息可以转移一个实体，否则 受请求方法或响应状态码限制。 实体 由实体头字段和实体主体组成，尽管有些 响应将仅包含实体标头。
简而言之：一个Entity可以被转移，它可以是header + body，或者只是header .
既然有上面的链接，我就留着做更多的cmets。
【讨论】：
实体类似于消息，它由标头组成，其中包含位置、语言、编码等元数据...
以及可选的正文 - 它的内容按照标题中指定的格式等
【讨论】：
最新的 HTTP 1.1 RFC 7230 使用术语 Payload 而不是实体。一些旧文档仍然引用旧术语。
关于实体（有效负载）要记住的重要实际事情是：
如果 Transfer-Encoding 不存在，Message Body = Entity(Payload) Body。
如果存在Transfer-Encoding，则必须通过适当的解码和提取来获得Entity(Payload) Body。
【讨论】：