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

[Paulo Faria]

I'm glad we can start talking in source code now. Chris sent me the link
before, so I had time to create a counterproposal concerning the 3 files
mentioned. In the readme I have the rationale for the design decisions. I
also used jazzy to create an API reference. Here are the links:

https://github.com/paulofaria/http-api-proposal
https://paulofaria.github.io/http-api-proposal/



On 26 May 2017 at 13:00, Chris Bailey via swift-server-dev <
swift-server-dev at swift.org> wrote:

> There's been a lot of discussion around the HTTP API spec originally
> created by Johannes Weiss with input of a number of other people
> (particularly Helga Hess):
>         https://lists.swift.org/pipermail/swift-server-dev/
> Week-of-Mon-20170403/000422.html
>
> Since then some work has been done by Carl Brown and others on a prototype
> of a clean (not derived from existing code) implementation of that API. You
> can find that prototype here:        https://github.com/carlbrown/
> HTTPSketch
>
> The API itself is essentially implemented in three files:
> HTTPRequest:        https://github.com/carlbrown/HTTPSketch/blob/master/
> Sources/HTTPSketch/HTTPRequest.swift
> HTTPResponse:        https://github.com/carlbrown/HTTPSketch/blob/master/
> Sources/HTTPSketch/HTTPResponse.swift
>
> HTTPCommon:        https://github.com/carlbrown/HTTPSketch/blob/master/
> Sources/HTTPSketch/HTTPCommon.swift
>
> The prototype has some dependencies on the CHTTParser and BlueSocket
> libraries from IBM-Swift in order to have working implementation, but we've
> attempted to abstract those away so that they're easily replaced with
> another implementation - eventually the aim is to move to standard
> implementations from the Server API project and to utilise the secure
> transport implementation being worked on under the Security stream.
>
> We're proposing to use this as the starting point and move it into the
> swift-server org on GitHub. From there we can then collaborate and iterate
> on improving/evolving the API surface and the implementation through
> discussion on the mailing list and PRs.
>
> The hope is that having an independent concrete implementation should make
> it much easier for us to iterate on and experiment with changes to the API
> and implementation as can all see how it affects a real implementation,
> including being able to assess performance and memory footprint costs of
> alternative approaches, etc.
>
> Please take a look. If people are happy to use this as an initial
> implementation of HTTP API spec that's been layed out so far, we'll move it
> over to the swift-server org on GitHub. This is by no means the final API
> or implementation - there's definitely lots that still needs to be
> discussed. Once its on the swift-server org we'll start looking at the API
> and implementation choices in-depth via the mailing list and PRs.
>
> Chris
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170526/39766f0d/attachment.html>