I think it would make more sense to have an http-core spec.
The basics of serving http as an api.
- no sessions
- no authentication
- no streaming apis
- always async (if you want blocking calls, do it yourself. none of this bolted on broken async that servlet has)
- no filters (this is just wrappers of the request or the response, and can be genericized)
- no listeners (pointless specialization, keep it generic)
- no url-pattern mappings (there's countless ways to map a request to an internal feature, let the users control how they want it)
- request is an interface (not an abstract class)
- response is an interface (not an abstract class)
- no complex war or ear magic
- no classloader isolation concerns
- no auto discovery of components
- no external configuration (xml, json, etc)
- entirely programmatic
This low level http api would be sufficient to build REST, Servlet, or whatever (grpc?) on top of.
The responsibilities of the http-api impls would be to handle the connections, the exchanges, the http/2+ streams, etc.
Transport concerns, compression, etc.
