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.
A user of the http-api would be able to control how the requests are handled, and provide the layers that they need.
I expect a healthy community to develop here to provide features (like single sign on, oauth, caching, sessions handling, etc) as standalone libraries that can be added into the handler tree of this http-api.
- Joakim
