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

[Helge Heß]

Hi,

> On 1. Jun 2017, at 21:07, Johannes Weiss via swift-server-dev <swift-server-dev at swift.org> wrote:
>> I have to admit that I tried to follow the discussion here, but I got lost. I do not see what all this asynch/kevent/... stuff has to do with an HTTP API.
>> 
>> Its probably me though. It happens… :-(
> 
> As one of the main offenders I can tell you that I don't quite understand it either.

yes, the discussion drifted off and is a little lost in arguments. But I don’t think it is actually hard to understand at all.

There are two main opinions:
A) there should be a callback based API only (Johannes)
B) there should be a synchronous API too     (Paulo)

If this effort goes with just A, I think it is kinda obvious that this won’t work for frameworks with a synchronous API. Not because it isn’t possible to implement it at all (I showed that it is w/ the Apache one), but because it isn’t possible to implement in a way which aligns with the higher level synchronous APIs of the frameworks (which are not callback based and don’t want to be callback based).


To resolve the situation one option would be to completely leave out the relevant parts and just have the parser, the request/response objects. And other stuff working just on top of that (e.g. cookies have been mentioned, auth decoding, utility stuff like that).
Talking API.md:

  https://github.com/modswift/http/blob/develop/API.md

Essentially remove: HTTPBodyHandler, HTTPBodyProcessing, HTTPBodyChunk.
They could still be used in a Dispatch based default implementation, but wouldn’t be ‘standard API’. But add: HTTPParser.


I think the *goal* of this group is a little mixed up or maybe unclear. My assumption was always that this provides a standard server implementation which higher level frameworks can build upon. It wouldn’t do middleware, Zope or WebObjects style processing, but it would definitely do all the HTTP server stuff. SSL, HTTP/2, eventloop etc. What `httplib` does in Python or `http` in Go. The user can just import the Swift module and off he goes. It's the standard Swift way to do HTTP servers and it is built in.
If he then wants fancy HTML templates, an integrated ORM and stuff like that, he’d use a framework build on top of that basic lib.
This IMO definitely implies that an I/O model and all that is chosen for the user.

On the other side people like Paulo (I think ;-) see the API more like just that, a common AP*Interface*. Only the common API is shared, everyone still has his own ’server' and eventually code on top of that is shared. Kinda the other way around.

So maybe the common goal should be clarified (or found) one more time. Or maybe I’m just completely wrong :-)

hh

P.S.: Some of my personal opinions, just to give some context, no need to discuss them at all:
- It would be great if Swift would have a HttpServer lib which you
  can just use
- If such exists it would be only confusing to provide two different
  APIs (in fact the other approaches may just die adoption wise as
  the standard, well, sets the standard :-)
- In general I’m mostly in favour of using async for the standard
  module (despite what follows)
- I think that async APIs are overrated. They are a must on very 
  highly scalable systems of certain kinds, but for many many types
  of deployments they are just not necessary.
- For most people programming against async APIs is a
  pain in the **, particularly w/ ARC. It just raises the complexity a
  lot. (which people then try to solve w/ more additional magic like
  Promises)
- Node.js changed that a little, but the far majority of web
  development is still done in traditional synchronous/threaded
  setups: WebObjects, PHP, Servlets, Rails. IMO for a good reason, 
  see above.
- If you use an async API and people end up doing `concat`, which
  is really common in Node .., you gained, well, nothing.