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

[Paulo Faria]

By the way. I also think we should consider Helge's suggestions of naming
for what is currently request and response. They are actually only the
request and response head, as Helge pointed. So it *does* make sense to
name it HTTPRequestHead and HTTPResponseHead.

On 27 May 2017 at 10:18, Paulo Faria <paulo at zewo.io> wrote:

> 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/1ed8988b/attachment-0001.html>