Unify the HTTP Apis (Jakarta HTTP)

[arjantijms]

Jakarta EE 10 has two competing APIs for HTTP handling; one provided by Servlet, the other by REST.

This is highly undesirable. Both users and other vendors need to learn / support two largely distinct APIs.
AB#51

[hantsy]

I hope there is a new standard API to unite common network operations, like Spring ServerExchange(adapt for different protocols, Http, WebSocket, RSocket, gRPC, etc) and DataBuffer(similar to ByteBuffer and Netty ByteBuf), use reactive/async by default.

Publisher<ServerRequest> request = exchange.getRequest();
Publisher<ServerResponse> request = exchange.getResponse();

Switch to blocking/sync by a simple method.

ServerRequest request = exchange.getRequest().toBlocking(an optional timeout);
ServerResponse request = exchange.getResponse().toBlocking();

(also create a client like this)

For Jakarta EE 11, we can consider virtual thread and construct concurrency from the scratch. And refactor the current Servlet, Rest spec, and also requires a context propagate(support sync and async automatically, recognized by all specs, esp CDI, EL, etc) to pass request state through different contexts without explicit copy etc.

[hantsy]

This is highly undesirable. Both users and other vendors need to learn / support two largely distinct APIs.

Maybe define a new specification, and refactor Rest and Servlet/Pages/Faces to use it as base.

[hantsy]

@edburns Why we need Azure to manage jakarta issues, https://dev.azure.com/jakarta-ee-azdo/jakarta-ee-azdo ?

[hantsy]

Helidon4 web server is rewritten from scratched, and embraces VT. The new Http Apis can be inspired from the existing work.

[AngeloRubens]

Hi All, during discussion on this thread(https://www.eclipse.org/lists/rest-dev/msg00332.html), proposed to write in this issue this proposal:

The concept like that of DataSource and jdbc Connection, brought back to http/https connections,
you could have a HttpSource(type DataSource api) that manages http connections referring to the standard http api introduced with java 11(https://docs.oracle.com/en/java/javase/21/docs/api/java.net.http/module-summary.html)a specific setting for each endpoint you want to make a request to and create the same metadata also for http and https connections.
Define this httpsource and http/s connection pool on the application server, and the module that needs the connection requests it to the AS, which takes care of managing the connections, the pool and the authentication mechanisms.

How do you think?

[hantsy]

Java 11 just includes the HttpClient API.

For my opinion, adopt the good parts from the existing framework, such as Spring WebFlux, Micronaut, Holiden, esp, Holiden includes a complete new WebServer written in Java 21 and Virtual Thread.

• Split Client/Server request/response.
• Cover blocking/asynchronous/reactive scenarios.
• Make Client possible to use switchable HttpClient Engine(JDK HttpClient, Apache HttpComponents, OkHttp, etc.), not depend on JDK11 HttpClient.

The most important for me, unite all web related spec to use the united Http APIs, thus we can handle Web/Rest API Security, global Web/Http Rest API related Exception Handling in one place, not for different spec. Currently, we mixed Faces, Pages/Servlet, REST/MVC in one application, it is not a good experience to resolve these problems.

[AngeloRubens]

Exactly, as happened for JPA to standardize the Orm (Hibernate, EclipseLink, Ibatis etc... etc...). To the points you listed above, I would add a pooling mechanism and definition of an HttpSource (like DataSource) that is configured and managed on the AS, on this HttpSource the sizing of the http/s connection pool, the authentication mechanism, the heartbeat/httpCheck for connection validation are configured. The application via cdi or lookup requires a connection to be used for a given endpoint.

[arjantijms]

How do you think?

The initial scope is intended to be kept quite small. Basically standardise acros the platform what's now HttpServletRequest and HttpServletResponse.

We have a type safe rest client here https://github.com/microprofile/microprofile-rest-client and a regular REST client in Jakarta REST. Both are essentially HTTP clients too. The type safe rest client forgot to really adress client side authentication mechanisms. We have those in Jakarta Authentication, but we all ignore them (granted, they were originally designed with SOAP in mind).

[hantsy]

The Microprofile RestClient effort can be merged into Jakarta Rest, jakartaee/rest#1294

[edburns]

@edburns Why we need Azure to manage jakarta issues, https://dev.azure.com/jakarta-ee-azdo/jakarta-ee-azdo ?

Because I was unable to figure out how to do what @jhanders34 is currently doing for EE 12 regarding issues that span Git repositories. But we'll use GitHub for 12.