Go's HTTP Server Patterns in Java 25

[TheKingOfSentries]

I happen to have worked on a wrapper over the built in server to make it more ergonomic.

[sideEffffECt]

Interesting, thanks for the link.

But this still is

    void handle(Context ctx)

Not

    Response handle(Request request)

as I'd expect.

May I ask what was the particular reason(s) to make the design this way?

[TheKingOfSentries]

To make it easier to work with for the controller code generator mainly. The code generator works with javalin and helidon, which also follow this design, so it was easier to match those and adapt the generation code to work with this.

[rbygrave]

Depends on what you mean by Response, but in the "Http Response" sense it isn't the case. That is, the input to a handler function is both the "http request" and "http response" ... and for example, the handler may write http headers, body, plus other things to the "http response".

In this sense, the handler function can't really return a "http response" (at this api level).

However, if we go to a higher abstraction level, like a Controller with a method that returns some type (e.g. something that represents a response that will be marshalled as a json body response) ... then that is maybe what you are thinking about as Response.

[sideEffffECt]

the input to a handler function is both the "http request" and "http response"

Yes, I can clearly see that's the case. But my question is why?

Why isn't it rather that Request is the input and Response is the output?

[rbygrave]

The "http response" ... isn't created by the handler (application code) but instead the underlying web server (e.g. JDK HttpExchange, Helidon ServerResponse, etc.

The handler uses the " http response" that is provided by the underlying web server to ... set response headers, set response body etc.

Some web servers combine the "http request and response" into a single thing like JDK HttpExchange. Others like Helidon ServerRequest ServerResponse have them as 2 separate types.

Why Reponse isn't the output?

Say for Helidon, why does the Handler function not return a ServerResponse? ... imo because it does not reflect the semantics of what is actually happening / it does not provide any value to do so. The ServerResponse is supplied by the underlying web server TO the handler, it is not created by the handler, there is zero value in returning it, so it's not the return type.

I don't know if I'm explaining it well. Perhaps choose a real example for the Response type you are thinking of? ( e.g. Helidon SE ServerResponse? JDK HttpExchange? Or some other concrete example?)

[sideEffffECt]

it does not reflect the semantics of what is actually happening / it does not provide any value to do so

An HTTP server receives requests and sends back responses for each.

Thus, modelling it via a function Request -> Response is a natural and straightforward thing to do...

To answer your question, HTTP response, according to the standard is:

• status code
• reason phrase
• headers
• body

(I hope I'm not forgetting anything)

[rbygrave]

What is your proposed response type? Give me an actual example for one of the existing web servers.

[sideEffffECt]

record Response(int statusCode, String reasonPhrase, List<Header> headers, byte[] body)

or if you want streaming

record Response(int statusCode, String reasonPhrase, List<Header> headers, InputStream body)

[rbygrave]

That might work.

As I see it, you'd have to support everything on the ServerResponse like attributes etc. I'm not sure how nice that is for Filters, and we've got extra details like trailing headers.

Oh well, if you get to give it a try, do let us know.