Exit Zen
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
65
string ID 431
type: list
English
* A body can only be extracted once, limiting the use of this container
71/710 · 71
66
string ID 434
type: list
English
* Setting the body requires either a vector or a `concurrency::streams::istream`.
81/810 · 81
67
string ID 437
type: list
English
* The HTTP request container conflates HTTP response behavior (see the
70/700 · 70
68
string ID 442
type: paragraph
English
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.
275/2750 · 275
69
string ID 447
type: paragraph
English
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).
512/5120 · 512
The translation has come to an end.