RubenVerborgh/solid-server-architecture

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 per HttpHandler? If this is not a typical use case, I would only allow one HttpServer per HttpHandler for simplicity (e.g. regarding cloning of request body streams in HttpRequest). If still needed for exotic cases, a HttpServerArray wrapper could always be created.
  • Why handle(HttpRequest, HttpResponse) : void and not handle(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 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.

  • Why handle(HttpRequest, HttpResponse) : void and not handle(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.