[swift-server-dev] HTTP API Sketch v2

[Helge Heß]

Hi,

On 9. Apr 2017, at 04:12, George Leontiev via swift-server-dev <swift-server-dev at swift.org> wrote:
> Earlier in this thread, I think someone dismissed protocols/generics because “at some point, we need to implement a concrete type”.

I don’t think anything was ‘dismissed’. The sole meaning was that there will be a Swift Server module and that this should/will come with a concrete type (so that people can have a minimal running http server out of the box by just using that module). You can still have protocols or whatever you chose.


> I think we can leverage the Swift type system to have something much better.
> 
> I recommend having protocols for HTTP{Request,Response}{Encodable,Decoder} types

<snip> protocols <snip>

Your `HTTPRequestEncodable` is in a way the reverse of Johannes’ HTTPResponseWriter. The advantage of the latter is that it also doesn’t enforce a specific response type and neither requires a type at all. W/ your approach there always has to be a type implementing the protocol.

I’m not entirely sure why you would call it `HTTPRequestEncodable`. I would just call it `HTTPRequest`? To me an `Encodable` has a method which provides another value (the encoded representation). Like this:

  protocol HTTPRequestEncodable {
    func encodeAsHTTPRequest() -> HTTPRequest
  }

which may still be useful. But extra indirections :-)


Your `HTTPRequestDecoder` is like a parser delegate, kinda like the peer to the `HTTPResponseWriter`. Could be done like this.
Though if you provide an “Encodable” I suppose the assumption would be that you also provide a “Decodable” too ...


> I can flesh out the APIs more if people are interested, but I think this is sufficient to communicate the idea, and I’d love to hear more feedback. 

A complete proposal like Johannes’ would be more useful. Or maybe even better a revision of Johannes’ proposal with your ideas in it.


> There is a performance overhead to using protocols/generics, but I believe these can be effectively mediated by the compiler.

I don’t see how you would eliminate the protocol overhead cross-module. But I think it should be small enough (after all the proposal also uses Strings ;-).

hh