Zen

Translation

type: paragraph
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.
654/6540 · 654

Sign in to save translations.

Key English Chinese (Simplified Han script) Actions
* The [*Body] customization point constrains user defined types to
* The [*Body] customization point constrains user defined types to
This representation addresses a narrow range of use cases. It has limited potential for customization and performance. It is more difficult to use because it excludes the start line fields from the model.
This representation addresses a narrow range of use cases. It has limited potential for customization and performance. It is more difficult to use because it excludes the start line fields from the model.
C++ REST SDK (cpprestsdk)
C++ REST SDK (cpprestsdk)
is a Microsoft project which ['"...aims to help C++ developers connect to and interact with services"]. It offers the most functionality of the libraries reviewed here, including support for Websocket services using its websocket++ dependency. It can use native APIs such as HTTP.SYS when building Windows based applications, and it can use Boost.Asio. The WebSocket module uses Boost.Asio exclusively.
is a Microsoft project which ['"...aims to help C++ developers connect to and interact with services"]. It offers the most functionality of the libraries reviewed here, including support for Websocket services using its websocket++ dependency. It can use native APIs such as HTTP.SYS when building Windows based applications, and it can use Boost.Asio. The WebSocket module uses Boost.Asio exclusively.
As cpprestsdk is developed by a large corporation, it contains quite a bit of functionality and necessarily has more interfaces. We will break down the interfaces used to model messages into more manageable pieces. This is the container used to store the HTTP header fields: ``` class http_headers { public:
As cpprestsdk is developed by a large corporation, it contains quite a bit of functionality and necessarily has more interfaces. We will break down the interfaces used to model messages into more manageable pieces. This is the container used to store the HTTP header fields: ``` class http_headers { public:
254
private:
private:
256
}; ```
}; ```
This declaration is quite bare-bones. We note the typical problems of most field containers:
This declaration is quite bare-bones. We note the typical problems of most field containers:
* The container may only be default-constructed.
* The container may only be default-constructed.
* No support for allocators, stateful or otherwise.
* No support for allocators, stateful or otherwise.
* There are no customization points at all.
* 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 {
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 {
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.
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.
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:
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:
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__:
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__:
* The constructor accepting `std::unique_ptr<http::details::_http_server_context`
* The constructor accepting `std::unique_ptr<http::details::_http_server_context`
* The "cancellation token" is stored inside the message. This breaks the
* The "cancellation token" is stored inside the message. This breaks the
* The `_reply_impl` function implies that the message implementation also
* The `_reply_impl` function implies that the message implementation also
Finally, here is the public class which represents an HTTP request: ``` class http_request { public:
Finally, here is the public class which represents an HTTP request: ``` 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:
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:
* There are no compile-time customization points at all. The only
* There are no compile-time customization points at all. The only
* The extraction of the body is conflated with the asynchronous model.
* The extraction of the body is conflated with the asynchronous model.
* No way to define an allocator for the container used when extracting
* No way to define an allocator for the container used when extracting
English Chinese (Simplified Han script) Actions
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.
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.
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:
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:
} // 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__:
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__:
* The constructor accepting `std::unique_ptr<http::details::_http_server_context`
* The constructor accepting `std::unique_ptr<http::details::_http_server_context`
* No support for allocators, stateful or otherwise.
* No support for allocators, stateful or otherwise.
HTTP Comparison to Other Libraries
HTTP Comparison to Other Libraries
There are a few C++ published libraries which implement some of the HTTP protocol. We analyze the message model chosen by those libraries and discuss the advantages and disadvantages relative to Beast.
There are a few C++ published libraries which implement some of the HTTP protocol. We analyze the message model chosen by those libraries and discuss the advantages and disadvantages relative to Beast.
The general strategy used by the author to evaluate external libraries is as follows:
The general strategy used by the author to evaluate external libraries is as follows:
* Review the message model. Can it represent a complete request or
* Review the message model. Can it represent a complete request or
* Review the stream abstraction. This is the type of object, such as
* Review the stream abstraction. This is the type of object, such as
* Check treatment of buffers. Does the library manage the buffers
* Check treatment of buffers. Does the library manage the buffers
* How does the library handle corner cases such as trailers,
* How does the library handle corner cases such as trailers,
Declarations examples from external libraries have been edited:
Declarations examples from external libraries have been edited:
cpp-netlib
cpp-netlib
is a network programming library previously intended for Boost but not having gone through formal review. As of this writing it still uses the Boost name, namespace, and directory structure although the project states that Boost acceptance is no longer a goal. The library is based on Boost.Asio and bills itself as ['"a collection of network related routines/implementations geared towards providing a robust cross-platform networking library"]. It cites ['"Common Message Type"] as a feature. As of the branch previous linked, it uses these declarations: ``` template <class Tag> struct basic_message {
is a network programming library previously intended for Boost but not having gone through formal review. As of this writing it still uses the Boost name, namespace, and directory structure although the project states that Boost acceptance is no longer a goal. The library is based on Boost.Asio and bills itself as ['"a collection of network related routines/implementations geared towards providing a robust cross-platform networking library"]. It cites ['"Common Message Type"] as a feature. As of the branch previous linked, it uses these declarations: ``` template <class Tag> struct basic_message {

Loading…

User avatar admin

String added in the repository
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.
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.
06/05/2026
Browse all string changes

Things to check

Unchanged translation

Source and translation are identical.

Reset

Glossary

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

String information

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