[swift-server-dev] Next HTTP API meeting

[Alex Blewitt]

> On 23 Mar 2017, at 09:51, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> Here's an example of a protocol required to parse a request

I agree in principle, thinking in protocols is a good way of defining what an API should look like and how it should interact.

> ```
> protocol HTTPMessage {
>     init(status: String, version: String, method: String, headers: [String: String], etc...
> }
> ```

This is a good example, in that it brings up a number of other questions. For example: the 'status' is a String here. Why not an enum or an int?

In addition, the headers are a dictionary of [String:String]. However, HTTP headers can be repeated and it's possible to get the first or a list of values for the repeated header, so using a dictionary isn't sufficient. In addition the headers dictionary has an implicit assumption about the fact they're stored as values (for example). You'd need to have a separate protocol for representing the headers in order to permit multiple implementations.

Discussing the protocols helps understand the problems from two perspectives; from an end user's view of the software, and from a framework implementor's view of the software.

> It doesn't need to be anything particularly complex, and we could include easily the inverse as well for the serializer. This could be a distinct protocol even for use cases we might not consider.
> 
> I'd like to just put up a quick reminder that we're not building a framework here, we're building core apis that are intended to be flexible and useful for framework developers. With something like this, we could easily conform foundation's URLRequest or NSURLRequest by default so basic users could use those built in without much effort, but framework developers wouldn't be stuck constantly dealing with non-native objects or doing unnecessary conversions.
> 
> This doesn't take away from anything that has been proposed so far, and creates additional capabilities and flexibilities for a system that is intended to be just that ... flexible. In general, I think it's important for us to remind ourselves what we're building and that creating the most flexible possible code will make the library more lasting and allow users to create unique and interesting interactions that we might not have even considered in our narrow scope. We want to support and encourage this creativity, not stifle it, wherever possible. Looking forward to working through more of this.


Alex