HTTP Outbound Components

本节介绍 Spring Integration 的 HTTP 出站组件。

This section describes Spring Integration’s HTTP outbound components.

Using HttpRequestExecutingMessageHandler

要配置 HttpRequestExecutingMessageHandler，请编写类似于以下内容的 bean 定义：

To configure the HttpRequestExecutingMessageHandler, write a bean definition similar to the following:

<bean id="httpOutbound"
  class="org.springframework.integration.http.outbound.HttpRequestExecutingMessageHandler">
  <constructor-arg value="http://localhost:8080/example" />
  <property name="outputChannel" ref="responseChannel" />
</bean>

此 bean 定义通过委托给 RestTemplate 来运行 HTTP 请求。该模板反过来委托给 HttpMessageConverter 实例列表，以根据 消息 有效载荷生成 HTTP 请求正文。你可以配置这些转换器以及要使用的 ClientHttpRequestFactory 实例，如下例所示：

This bean definition runs HTTP requests by delegating to a RestTemplate. That template, in turn, delegates to a list of HttpMessageConverter instances to generate the HTTP request body from the Message payload. You can configure those converters as well as the ClientHttpRequestFactory instance to use, as the following example shows:

<bean id="httpOutbound"
  class="org.springframework.integration.http.outbound.HttpRequestExecutingMessageHandler">
  <constructor-arg value="http://localhost:8080/example" />
  <property name="outputChannel" ref="responseChannel" />
  <property name="messageConverters" ref="messageConverterList" />
  <property name="requestFactory" ref="customRequestFactory" />
</bean>

默认情况下，HTTP 请求是通过使用 SimpleClientHttpRequestFactory 实例生成的，该实例使用 JDK HttpURLConnection。还支持通过 CommonsClientHttpRequestFactory 使用 Apache Commons HTTP 客户端，你可以注入（如前所示）。

By default, the HTTP request is generated by using an instance of SimpleClientHttpRequestFactory, which uses the JDK HttpURLConnection. Use of the Apache Commons HTTP Client is also supported through CommonsClientHttpRequestFactory, which you can inject (as shown earlier).

对于出站网关，网关生成的回复消息包含请求消息中出现的所有消息头。

For the outbound gateway, the reply message produced by the gateway contains all the message headers that are present in the request message.

Using Cookies

出站网关上“transfer-cookies”属性提供基本 Cookie 支持。当设置为 true 时（默认值为 false），从服务器接收到的响应中的 Set-Cookie 标头会转换为回复消息中的 Cookie。然后，此标头在随后的发送中使用。这可以实现简单的有状态交互，如下所示：

Basic cookie support is provided by the transfer-cookies attribute on the outbound gateway. When set to true (the default is false), a Set-Cookie header received from the server in a response is converted to Cookie in the reply message. This header is then used on subsequent sends. This enables simple stateful interactions, such as the following:

…​→logonGateway→…​→doWorkGateway→…​→logoffGateway→…​

如果 transfer-cookies 为 false，则任何接收到的 Set-Cookie 标头将保留为回复消息中的 Set-Cookie，并在随后的发送中丢弃。

If transfer-cookies is false, any Set-Cookie header received remains as Set-Cookie in the reply message and is dropped on subsequent sends.

Empty Response Bodies

HTTP 是一个请求-响应协议。但是，响应可能没有正文，只有标头。在这种情况下，HttpRequestExecutingMessageHandler 会生成一个回复 Message，其中有效负载为 org.springframework.http.ResponseEntity，而不管提供了什么 expected-response-type。根据 HTTP RFC Status Code Definitions，许多状态要求响应一定不包含消息体（例如，204 No Content）。在某些情况下，对同一个 URL 的调用可能会或可能不会返回响应实体。例如，对 HTTP 资源的第一个请求返回内容，但第二个不返回内容（返回 304 Not Modified）。然而，在所有情况下，都会填充 http_statusCode 消息头。这可以在 HTTP 出站网关之后的一些路由逻辑中使用。您还可以使用`<payload-type-router/>` 将具有 ResponseEntity 的消息路由到与用于具有正文的响应不同的流中。

HTTP is a request-response protocol. However, the response may not have a body, only headers. In this case, the HttpRequestExecutingMessageHandler produces a reply Message with the payload being an org.springframework.http.ResponseEntity, regardless of any provided expected-response-type. According to the HTTP RFC Status Code Definitions, there are many statuses that mandate that a response must not contain a message-body (for example, 204 No Content). There are also cases where calls to the same URL might or might not return a response body. For example, the first request to an HTTP resource returns content, but the second does not (returning a 304 Not Modified). In all cases, however, the http_statusCode message header is populated. This can be used in some routing logic after the HTTP outbound gateway. You could also use a`<payload-type-router/>` to route messages with a ResponseEntity to a different flow than that used for responses with a body.
expected-response-type

除了前面关于空响应正文的注释之外，如果响应确实包含正文，你必须提供一个适当的 expected-response-type 属性，否则将再次收到一个没有正文的 ResponseEntity。expected-response-type 必须与（配置或默认）HttpMessageConverter 实例和响应中的 Content-Type 标头兼容。它可以是抽象类，甚至可以是接口（例如，使用 Java 序列化和 Content-Type: application/x-java-serialized-object 时的 java.io.Serializable）。

Further to the preceding note about empty response bodies, if a response does contain a body, you must provide an appropriate expected-response-type attribute or, again, you receive a ResponseEntity with no body. The expected-response-type must be compatible with the (configured or default) HttpMessageConverter instances and the Content-Type header in the response. This can be an abstract class or even an interface (such as java.io.Serializable when you use Java serialization and Content-Type: application/x-java-serialized-object).

从 5.5 版本开始，HttpRequestExecutingMessageHandler 公开了一个 extractResponseBody 标志（默认情况下为 true），以仅返回响应正文，或将整个 ResponseEntity 作为回复消息有效载荷返回，与提供的 expectedResponseType 无关。如果 ResponseEntity 中没有正文，则此标志将被忽略，并将返回整个 ResponseEntity。

Starting with version 5.5, the HttpRequestExecutingMessageHandler exposes an extractResponseBody flag (which is true by default) to return just the response body, or to return the whole ResponseEntity as the reply message payload, independently of the provided expectedResponseType. If a body is not present in the ResponseEntity, this flag is ignored and the whole ResponseEntity is returned.