So I’ve been reading about multi-threading these past few days. Can you give me a real life example where the multi-threading might be used in a REST API web server?
2 Answers
$\begingroup$
$\endgroup$
A web server serves hypertext transfer protocol requests. While there is no requirement whatsoever on arrival times and service times, the idea is a successful service sometimes gets requests even more frequently than $\frac 1 {\text service-time}$: for requests to neither be discarded nor queue up, there must be some concurrency in processing.
There are different approaches to unwanted and/or illegal disclosure of confidential data. Typically, threads sharing any given processor "core" concurrently enjoy identical access rights, while separate computers/processors/cores are restricted individually:
If serious about confidentiality, better restrict multi-threading to reducing the service time of single requests.
This is where the REST of the protocol (& API (client side, mainly)) comes into the picture:
Keeping all information feasible with the client and transferring it per request (REpresentational State Transfer) means identifying requests for the same confidentiality domain was extra effort.
$\begingroup$
$\endgroup$
There is a thesis turned into free (and open) book that covers pretty much every aspect of concurrent Web servers and applications (including REST): Concurrent Programming for Scalable Web Architectures (thanks to Benjamin Erb).
But the main idea is simple and old: as long as separate requests are independent from one another (and HTTP pretty much mandates that) we can process them completely separately and concurrently, i.e. each one in its own (logical) thread. Sure enough in the real world there are lots of nuances that make straightforward implementation not very practical and you need to "upgrade" this basic idea with various mechanisms (thread pool, connection pool, asynchronous IO, and so on).
