Zen

Translation

type: paragraph
As before, we note that the implementation class for HTTP requests concerns itself more with the mechanics of sending the message asynchronously than it does with actually modeling the HTTP message as described in __rfc7230__:
74/2260 · 226

Sign in to save translations.

Key English Chinese (Simplified Han script) Actions
254
private:
private:
256
}; ```
}; ```
This declaration is quite bare-bones. We note the typical problems of most field containers:
这个声明相当简陋。我们注意到大多数字段容器都存在一些典型问题：
* The container may only be default-constructed.
* 该容器只能进行默认构造。
* No support for allocators, stateful or otherwise.
* 不支持分配器，无论是有状态分配器还是其他类型的分配器。
* There are no customization points at all.
* 完全没有任何自定义点。
Now we analyze the structure of the larger message container. The library uses a handle/body idiom. There are two public message container interfaces, one for requests (`http_request`) and one for responses (`http_response`). Each interface maintains a private shared pointer to an implementation class. Public member function calls are routed to the internal implementation. This is the first implementation class, which forms the base class for both the request and response implementations: ``` namespace details {
现在，我们来分析更大的消息容器的结构。该库使用了句柄/主体惯用法（handle/body idiom）。它提供了两个公开的消息容器接口，一个用于请求（`http_request`），另一个用于响应（`http_response`）。每个接口都维护着一个指向实现类的私有共享指针。公开的成员函数调用会被路由到内部的实现。以下是第一个实现类，它构成了请求和响应实现类的基类： ``` namespace details {
class http_msg_base { public:
class http_msg_base { public:
protected:
protected:
306
}; ```
}; ```
To understand these declarations we need to first understand that cpprestsdk uses the asynchronous model defined by Microsoft's [@https://msdn.microsoft.com/en-us/library/dd504870.aspx [*Concurrency Runtime]]. Identifiers from the [@https://msdn.microsoft.com/en-us/library/jj987780.aspx [*`pplx` namespace]] define common asynchronous patterns such as tasks and events. The `concurrency::streams::istream` parameter and `m_data_available` data member indicates a lack of separation of concerns. The representation of HTTP messages should not be conflated with the asynchronous model used to serialize or parse those messages in the message declarations.
要理解这些声明，需要先了解 cpprestsdk 使用了微软的 [@https://msdn.microsoft.com/en-us/library/dd504870.aspx [*Concurrency Runtime]] 所定义的异步模型。来自 [@https://msdn.microsoft.com/en-us/library/jj987780.aspx [*`pplx` namespace]] 的标识符定义了任务和事件等通用异步模式。`concurrency::streams::istream` 参数和 `m_data_available` 数据成员表明存在关注点分离缺失的问题。在消息声明中，不应将 HTTP 消息的表示形式与用于序列化或解析这些消息的异步模型混为一谈。
The next declaration forms the complete implementation class referenced by the handle in the public interface (which follows after): ``` /// Internal representation of an HTTP request message. class _http_request final : public http::details::http_msg_base, public std::enable_shared_from_this<_http_request> { public:
以下声明构成了公开接口中的句柄所引用的完整实现类（该类位于后续）：``` /// HTTP 请求消息的内部表示。 class _http_request final : public http::details::http_msg_base, public std::enable_shared_from_this<_http_request> { public:
336
private:
private:
344
};
};
} // namespace details ```
} // namespace details ```
As before, we note that the implementation class for HTTP requests concerns itself more with the mechanics of sending the message asynchronously than it does with actually modeling the HTTP message as described in __rfc7230__:
与之前一样，可以看出，HTTP 请求的实现类更关注于异步发送消息的机制，而不是按照 __rfc7230__ 中的描述对 HTTP 消息进行实际建模：
* The constructor accepting `std::unique_ptr<http::details::_http_server_context`
* 接受 `std::unique_ptr<http::details::_http_server_context` 的构造函数
* The "cancellation token" is stored inside the message. This breaks the
* “取消令牌”被存储在消息内部。这破坏了
* The `_reply_impl` function implies that the message implementation also
* `_reply_impl` 函数意味着消息的实现也
Finally, here is the public class which represents an HTTP request: ``` class http_request { public:
最后，下面是代表 HTTP 请求的公共类：``` class http_request { public:
407
private:
private:
412
}; ```
}; ```
It is clear from this declaration that the goal of the message model in this library is driven by its use-case (interacting with REST servers) and not to model HTTP messages generally. We note problems similar to the other declarations:
从这个声明中可以清楚地看出，该库中消息模型的目标是由其用例（与 REST 服务器交互）驱动的，而不是为了对 HTTP 消息进行通用建模。我们注意到存在与其他声明类似的问题：
* There are no compile-time customization points at all. The only
* 完全没有编译期自定义点。唯一
* The extraction of the body is conflated with the asynchronous model.
* 消息体的提取与异步模型混为一谈。
* No way to define an allocator for the container used when extracting
* 无法为提取数据时所使用的容器定义分配器
* A body can only be extracted once, limiting the use of this container
* 消息体只能提取一次，这限制了该容器的使用
* Setting the body requires either a vector or a `concurrency::streams::istream`.
* 设置消息体需要使用向量或 `concurrency::streams::istream`。
* The HTTP request container conflates HTTP response behavior (see the
* HTTP 请求容器混淆了 HTTP 响应行为（见
The general theme of the HTTP message model in cpprestsdk is "no user definable customizations". There is no allocator support, and no separation of concerns. It is designed to perform a specific set of behaviors. In other words, it does not follow the open/closed principle.
cpprestsdk 中 HTTP 消息模型的总体主题是“不支持用户可定义的自定义功能”。它没有分配器支持，也没有关注点分离。它的设计目的是执行特定的行为集。换句话说，它没有遵循开闭原则。
Tasks in the Concurrency Runtime operate in a fashion similar to `std::future`, but with some improvements such as continuations which are not yet in the C++ standard. The costs of using a task based asynchronous interface instead of completion handlers is well documented: synchronization points along the call chain of composed task operations which cannot be optimized away. See: [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3747.pdf [*A Universal Model for Asynchronous Operations]] (Kohlhoff).
Concurrency Runtime 中的任务操作方式与 `std::future` 类似，但进行了一些改进，例如 C++ 标准中尚未包含的 continuation（续体）。使用基于任务的异步接口而非完成处理程序（completion handlers）的代价已有详细记录：在组合任务操作的调用链上存在无法优化的同步点。参见：[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3747.pdf [*A Universal Model for Asynchronous Operations]] (Kohlhoff)。
English Chinese (Simplified Han script) Actions
* A body can only be extracted once, limiting the use of this container
* 消息体只能提取一次，这限制了该容器的使用
* No stateful allocator support.
* 不支持有状态分配器。
* The header and body containers may only be default-constructed.
* 头部和主体容器只能通过默认构造函数进行构造。
* The library uses specializations of `string<Tag>` to change the type
* 该库使用 `string<Tag>` 的特化来改变类型
Boost.HTTP
Boost.HTTP
* This container cannot model a complete message. The ['start-line] items
* 该容器无法对完整的消息进行建模。['start-line] 项
* The [*Body] customization point constrains user defined types to
* [*Body] 自定义点将用户自定义类型限制为
* The declarations imply that `std::vector` is a model of [*Body].
* 这些声明暗示 `std::vector` 是 [*Body] 的一个模型。
C++ REST SDK (cpprestsdk)
C++ REST SDK (cpprestsdk)
* The container may only be default-constructed.
* 该容器只能进行默认构造。
* The "cancellation token" is stored inside the message. This breaks the
* “取消令牌”被存储在消息内部。这破坏了
* No support for allocators, stateful or otherwise.
* 不支持分配器，无论是有状态分配器还是其他类型的分配器。
* There are no customization points at all.
* 完全没有任何自定义点。
Now we analyze the structure of the larger message container. The library uses a handle/body idiom. There are two public message container interfaces, one for requests (`http_request`) and one for responses (`http_response`). Each interface maintains a private shared pointer to an implementation class. Public member function calls are routed to the internal implementation. This is the first implementation class, which forms the base class for both the request and response implementations: ``` namespace details {
现在，我们来分析更大的消息容器的结构。该库使用了句柄/主体惯用法（handle/body idiom）。它提供了两个公开的消息容器接口，一个用于请求（`http_request`），另一个用于响应（`http_response`）。每个接口都维护着一个指向实现类的私有共享指针。公开的成员函数调用会被路由到内部的实现。以下是第一个实现类，它构成了请求和响应实现类的基类： ``` namespace details {
To understand these declarations we need to first understand that cpprestsdk uses the asynchronous model defined by Microsoft's [@https://msdn.microsoft.com/en-us/library/dd504870.aspx [*Concurrency Runtime]]. Identifiers from the [@https://msdn.microsoft.com/en-us/library/jj987780.aspx [*`pplx` namespace]] define common asynchronous patterns such as tasks and events. The `concurrency::streams::istream` parameter and `m_data_available` data member indicates a lack of separation of concerns. The representation of HTTP messages should not be conflated with the asynchronous model used to serialize or parse those messages in the message declarations.
要理解这些声明，需要先了解 cpprestsdk 使用了微软的 [@https://msdn.microsoft.com/en-us/library/dd504870.aspx [*Concurrency Runtime]] 所定义的异步模型。来自 [@https://msdn.microsoft.com/en-us/library/jj987780.aspx [*`pplx` namespace]] 的标识符定义了任务和事件等通用异步模式。`concurrency::streams::istream` 参数和 `m_data_available` 数据成员表明存在关注点分离缺失的问题。在消息声明中，不应将 HTTP 消息的表示形式与用于序列化或解析这些消息的异步模型混为一谈。
The next declaration forms the complete implementation class referenced by the handle in the public interface (which follows after): ``` /// Internal representation of an HTTP request message. class _http_request final : public http::details::http_msg_base, public std::enable_shared_from_this<_http_request> { public:
以下声明构成了公开接口中的句柄所引用的完整实现类（该类位于后续）：``` /// HTTP 请求消息的内部表示。 class _http_request final : public http::details::http_msg_base, public std::enable_shared_from_this<_http_request> { public:
As before, we note that the implementation class for HTTP requests concerns itself more with the mechanics of sending the message asynchronously than it does with actually modeling the HTTP message as described in __rfc7230__:
与之前一样，可以看出，HTTP 请求的实现类更关注于异步发送消息的机制，而不是按照 __rfc7230__ 中的描述对 HTTP 消息进行实际建模：
Finally, here is the public class which represents an HTTP request: ``` class http_request { public:
最后，下面是代表 HTTP 请求的公共类：``` class http_request { public:
It is clear from this declaration that the goal of the message model in this library is driven by its use-case (interacting with REST servers) and not to model HTTP messages generally. We note problems similar to the other declarations:
从这个声明中可以清楚地看出，该库中消息模型的目标是由其用例（与 REST 服务器交互）驱动的，而不是为了对 HTTP 消息进行通用建模。我们注意到存在与其他声明类似的问题：
* Setting the body requires either a vector or a `concurrency::streams::istream`.
* 设置消息体需要使用向量或 `concurrency::streams::istream`。
The general theme of the HTTP message model in cpprestsdk is "no user definable customizations". There is no allocator support, and no separation of concerns. It is designed to perform a specific set of behaviors. In other words, it does not follow the open/closed principle.
cpprestsdk 中 HTTP 消息模型的总体主题是“不支持用户可定义的自定义功能”。它没有分配器支持，也没有关注点分离。它的设计目的是执行特定的行为集。换句话说，它没有遵循开闭原则。
class http_msg_base { public:
class http_msg_base { public:
protected:
protected:
HTTP Comparison to Other Libraries
HTTP 与其他库的比较

Loading…

User avatar Bstran

Translation changed
As before, we note that the implementation class for HTTP requests concerns itself more with the mechanics of sending the message asynchronously than it does with actually modeling the HTTP message as described in __rfc7230__:
As before, we note that the implementation class for HTTP requests concerns itself more with the mechanics of sending the message asynchronously than it does with actually modeling the HTTP message as described in __rfc7230__:与之前一样，可以看出，HTTP 请求的实现类更关注于异步发送消息的机制，而不是按照 __rfc7230__ 中的描述对 HTTP 消息进行实际建模：
06/20/2026
User avatar admin

String added in the repository
As before, we note that the implementation class for HTTP requests concerns itself more with the mechanics of sending the message asynchronously than it does with actually modeling the HTTP message as described in __rfc7230__:
As before, we note that the implementation class for HTTP requests concerns itself more with the mechanics of sending the message asynchronously than it does with actually modeling the HTTP message as described in __rfc7230__:
06/05/2026
Browse all string changes

Glossary

English Chinese (Simplified Han script)
No related strings found in the glossary.

String information

Source string description
type: paragraph
Unit identifier
58669
Source string location
string ID 349
String age
06/05/2026
Last updated
06/26/2026
Source string age
06/05/2026
Translation file QuickBook file
doc/qbk/08_design/2_http_comparison_zh_Hans.qbk, string 54