[swift-server-dev] Prototype of the discussed HTTP API Spec

[Paulo Faria]

Michael, I narrowed the scope of the proposal and focused the rationale. I
answered your comments about switch for HTTPMethod and HTTPStatus.
Basically, we can switch on them because I implemented the pattern matching
operator ~=. I also removed the HTTPMessage as it is not *needed* and users
can define it and make HTTPRequest and HTTPResponse conform to it in
extensions in their own module.

https://github.com/paulofaria/http-api-proposal#rationale

Carl, Helge, Chris and Rien what do you think about the code? This is
pretty close to what Carl suggested.

The main differences are..

HTTPVersion as a struct.
HTTPHeaders backed by a single array storage and case insensitive checking
is done with the Field type to improve performance.
HTTPMethod as a struct instead of enum with pattern matching added allowing
switch cases. (pointed by Helge)
HTTPStatus as a struct instead of enum with pattern matching added allowing
switch cases. (pointed by Helge)

Apart from that there's only naming differences. I added some tests to
showcase what I mentioned.

https://github.com/paulofaria/http-api-proposal/blob/master/Tests/HTTPTests/HTTPTests.swift

On 27 May 2017 at 08:41, Michael Chiu <hatsuneyuji at icloud.com> wrote:

> The thing is, as I have mentioned before if we move on that route we have
> to have a well defined structure before hand, for example, there’s no such
> protocol “Message” in what Johannes proposed.
>
> As Chris and Carl mentioned before, this is only a prototype of the
> discussed API, so at least we have something to test, experiment and
> branchmark on.
>
> Also things like WebApp in Johannes’ proposal can easily remove without
> huge changes, since WebApp is simply a typealias. I really don’t think
> that’s a big issue, every other parts of the prototype is in fact pretty
> http-specific.
>
> Yes the prototype might dependent on some other frameworks like blue
> socket, but that’s how we can at least test and branchmark.
>
> Sincerely
> Michael
>
>
> On May 27, 2017, at 4:06 AM, Paulo Faria <paulo at zewo.io> wrote:
>
> Sorry if I'm being annoying, but I really feel what we lack is process.
> There's no formal proposal and proposal review. I really think we should
> move incrementally with well defined scopes and deadlines for every round.
> We didn't have that so far. Carl and others said that my suggestion is
> counter productive. I think the opposite, of course, as what I'm proposing
> is a well defined process where when we settle on a design for a particular
> set of base APIs then we move on to a higher absctraction. This way we
> won't be discussing the same things over and over again. I'll repeat, if we
> can't agree on the base types how can we move on? I'm saying let's first
> *settle* on Version, Headers, Message, Request and Response. Really
> *define* the API so then we move on, incrementally, from lower abstraction
> to higher abstraction.
>
>
>
> On May 27, 2017 07:53, "Paulo Faria" <paulo at zewo.io> wrote:
>
>> I'm just proposing we move the code incrementally. The "most consentual"
>> list I sent yesterday isn't radically different from the code Johannes
>> proposed. I really don't want to discuss this over and over, ad infinitum.
>> The most important in the messages I sent before is that we need a well
>> defined process. We don't have it. Just taking the first implementation,
>> with a lot of things that admitedly don't fit the scope, and adding that so
>> we can rework doesn't feel right to me. I'm actually confused about the
>> scope this project is taking. The code there explicitly mentions a WebApp,
>> which is a higher responsibility than HTTP. When we started this project
>> the scope as very clear. Crypto/TLS, Socket, HTTP. A well designed HTTP
>> module shouldn't depend *at all* on the socket implementation. Providing an
>> implementation would be just a matter of injecting a dependency. Moving
>> that code as is to the org really doesn't feel right to me. All I'm saying
>> is that we definitely should start having code on the org. But I say we
>> move first Version, Headers, Message, Request, Response. And again, the
>> "least controversial" I sent yesterday isn't radically strange. It's an
>> evolution of Johaness original proposal, plus Carl's, plus Helge's
>> suggestions, plus my suggestions. The only thing I added that wasn't
>> discussed before is HTTPHeader.Field which does a case insensitive
>> comparison in its equatable implementation, and the Message protocol which
>> holds the properties common to request and response (version and headers).
>> If we can't agree on that, which is the sum of everything that was
>> discussed about these particular types. How can we agree on that full
>> implementation?
>>
>> On May 27, 2017 05:13, "Michael Chiu" <hatsuneyuji at icloud.com> wrote:
>>
>>> Hi Carl
>>>
>>>
>>> >       This email thread isn’t about an API proposal. It’s about a
>>> prototype implementation of an API that was already proposed and discussed
>>> a month and a half ago.  The prototype isn't a full-featured framework like
>>> Vapor or Kitura, but it does actually work and it even has XCTests with
>>> decent (>75%) code coverage.
>>>
>>> I see, I was confused by the email contents instead of reading the
>>> subject and thought we are finally implementing some code. TBH, I don’t see
>>> any reason why this should not move to swift-server on github, It sounds a
>>> good start to me.
>>> Thank you guys’ hard work for building it.
>>>
>>> >       Also, please note that I didn’t play any part in proposing this
>>> API back in March/April - it’s not “Carl’s proposal.”  I just took the
>>> existing API that the group had previously discussed and implemented enough
>>> of it so that we could measure the utility and performance of the API as
>>> proposed and so that we could have better informed discussions about
>>> potential alternatives.
>>>
>>> You’re right. it was Johannes’ proposal, I’m so sorry for that.
>>>
>>> Michael.
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170527/41e1c394/attachment.html>