Feedback on HTTP layer
rubensworks opened this issue · 2 comments
This issue summarizes some thoughts I had on the HTTP layer:
- I assume that
HttpHandler#canHandle()
is there to enable multiple implementations to coexists in a bus-like system? - Are there any real use cases for having more than one
HttpServer
perHttpHandler
? If this is not a typical use case, I would only allow oneHttpServer
perHttpHandler
for simplicity (e.g. regarding cloning of request body streams inHttpRequest
). If still needed for exotic cases, aHttpServerArray
wrapper could always be created. - Why
handle(HttpRequest, HttpResponse) : void
and nothandle(HttpRequest) : Promise<HttpResponse>
? - I would use
HttpServer#listen(port : int) : Promise<void>
, so that you can await until started, and catch errors (such as port already bound). (same for#handle
if my previous suggestion will not be applied)
- I assume that
HttpHandler#canHandle()
is there to enable multiple implementations to coexists in a bus-like system?
Yeah, there could be different handlers for static assets, query, etc. This diagram only covers the LDP part, and how that would fit in a larger architecture.
- Are there any real use cases for having more than one
HttpServer
perHttpHandler
?
No, is this implied anywhere? I didn't put an explicit 1; the intention was to say that a server has multiple handlers.
- Why
handle(HttpRequest, HttpResponse) : void
and nothandle(HttpRequest) : Promise<HttpResponse>
?
Because the handler is not responsible for creating the response; the server is. The handler just adds stuff to it.
- I would use
HttpServer#listen(port : int) : Promise<void>
, so that you can await until started, and catch errors (such as port already bound).
Yeah, can do!
Are there any real use cases for having more than one HttpServer per HttpHandler?
No, is this implied anywhere? I didn't put an explicit 1; the intention was to say that a server has multiple handlers.
Ah, nvm, I misinterpreted the *
position in UML.
I agree with all the other comments above.