Exit Zen
45
string ID 268
type: paragraph
English
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 {
517/5170 · 517
46
string ID 279
type: paragraph
English
class http_msg_base { public:
29/290 · 29
47
string ID 294
type: paragraph
English
protected:
10/100 · 10
306
string ID 306
type: paragraph
English
}; ```
6/100 · 6
49
string ID 309
type: paragraph
English
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
50
string ID 319
type: paragraph
English
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:
318/3180 · 318
336
string ID 336
type: paragraph
English
private:
8/100 · 8
344
string ID 344
type: paragraph
English
};
2/100 · 2
53
string ID 346
type: paragraph
English
} // namespace details ```
26/260 · 26
54
string ID 349
type: paragraph
English
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__:
226/2260 · 226
55
string ID 353
type: list
English
* The constructor accepting `std::unique_ptr<http::details::_http_server_context`
81/810 · 81
56
string ID 357
type: list
English
* The "cancellation token" is stored inside the message. This breaks the
72/720 · 72
57
string ID 360
type: list
English
* The `_reply_impl` function implies that the message implementation also
73/730 · 73
58
string ID 364
type: paragraph
English
Finally, here is the public class which represents an HTTP request: ``` class http_request { public:
100/1000 · 100
407
string ID 407
type: paragraph
English
private:
8/100 · 8
412
string ID 412
type: paragraph
English
}; ```
6/100 · 6
61
string ID 415
type: paragraph
English
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:
236/2360 · 236
62
string ID 420
type: list
English
* There are no compile-time customization points at all. The only
65/650 · 65
63
string ID 426
type: list
English
* The extraction of the body is conflated with the asynchronous model.
70/700 · 70
64
string ID 428
type: list
English
* No way to define an allocator for the container used when extracting
70/700 · 70