Current HTTP implementation - as far as I am aware - uses a single request to manipulate(GET, POST,...) a single remote resource.
This is network ineffective if you want to process many(e.g.: 1-20?) smaller requests (with small response bodies) to e.g.: display the main page with a lot of joined information - e.g.: 10 recipes with their ratings, authors, first of most positive comments,...
Example
The example from the description section above could e.g.: produce the following requests to backend service:
1. GET /recipes?page=1 (fetches 10 recipes)
2. 10x GET /recipe/{id}/rating (fetches rating for single recipe)
3. 10x GET /recipe/{id}/top-comment (fetches top comment for single recipe)
Because this is network ineffective, developers either create single endpoints to retrieve such joined data or somehow proxy them, cache them, microservice them, etc...
The main points are that it seems an HTTP endpoint no longer represents a resource, but rather a portion of complex joined data, and that performance and data isolation are getting out of hand.
Requirements
Add virtual request to HTTP protocol.
The virtual request would encapsulate multiple concrete requests and would serialize/deserialize and wait for completion as a single unit.
Advantages of such a request would be that it would take only two network jumps to handle (virtual request's request and response).
Also, different backend frameworks could implement their own handlers for such requests and e.g.: create only a single thread for it. Such a handler would route the requests to the concrete endpoints (-> no need to change application code at all), wait for all of them to complete, and send a single response containing all of the actual responses.
Application Domain: General web app with HTTP API
Description
Current HTTP implementation - as far as I am aware - uses a single request to manipulate(GET, POST,...) a single remote resource. This is network ineffective if you want to process many(e.g.: 1-20?) smaller requests (with small response bodies) to e.g.: display the main page with a lot of joined information - e.g.: 10 recipes with their ratings, authors, first of most positive comments,...
Example
The example from the description section above could e.g.: produce the following requests to backend service:
Because this is network ineffective, developers either create single endpoints to retrieve such joined data or somehow proxy them, cache them, microservice them, etc...
The main points are that it seems an HTTP endpoint no longer represents a resource, but rather a portion of complex joined data, and that performance and data isolation are getting out of hand.
Requirements
Add virtual request to HTTP protocol. The virtual request would encapsulate multiple concrete requests and would serialize/deserialize and wait for completion as a single unit.
Advantages of such a request would be that it would take only two network jumps to handle (virtual request's request and response).
Also, different backend frameworks could implement their own handlers for such requests and e.g.: create only a single thread for it. Such a handler would route the requests to the concrete endpoints (-> no need to change application code at all), wait for all of them to complete, and send a single response containing all of the actual responses.