The example web service from the previous two parts of this series (Part 1, Part 2) lacks a bit of clarity, even though it only covers a few hundred lines. It starts with the fact that he requests in a if/else-Cascade distinguishes between URL path and HTTP method and executes the appropriate block of code for each. With only two or three possible options, that might just about work, but when there are more, you quickly lose track.
On top of that, it’s all done in a single method, the class http_worker, which is responsible for handling all connections. On a high-resolution monitor in portrait format, you can only see the full code of the class with a font size of 5 points, which in itself is a reason to use the scissors to move one or the other code snippet somewhere else. However, that weighs more heavily http_worker is functionally opaque because it performs three fundamental tasks at the same time: accepting, routing and handling requests.
The definition of the routing, i.e. which endpoint should trigger which action, is much better placed in a central place: in the main()-Function of the web service, where also the http_worker, whose threads and I/O context are spawned. And all actions are sensibly divided into one or more files as handler functions. If you then dem http_worker the routing information must be included in its method process_request() only instruct the router to forward the request, but no longer decide on this yourself.
