search

apple / swift-nio

Event-driven network application framework for high performance protocol servers & clients, non-blocking.
https://swiftpackageindex.com/apple/swift-nio/documentation
Apache License 2.0
7.93k stars 643 forks source link

Split basic HTTP types into separate package #2028

Closed tkrajacic closed 2 years ago

tkrajacic commented 2 years ago

Types like HTTPMethod, HTTPHeaders, etc. are very useful in contexts outside NIO.

Libraries like Alamofire, that are primarily used on clients do not import NIO, and have their own copy of implementation for those types (HTTPHeaders, HTTPMethod, HTTPResponseStatus) that are mostly copies of the same.

It would be convenient to split out those types from NIO (I created a blunt sample repo here) so packages that are used in client contexts without NIO, and server code where NIO is usually imported anyway, could rely on the same types.

Especially now that NIO 3.0 might be on the horizon, this would be the right time for such a change.

Strobocop commented 2 years ago

Currently facing this exact issue in our codebase.

stevapple commented 2 years ago

I thought this package is related👀 But not sure how we should deal with it. I guess no SSWG project is using it at the time.

apple/swift-http-structured-headers

Lukasa commented 2 years ago

Thanks for filing this!

Ultimately, the types that exist in NIO HTTP1 are purpose-built for our use-case. They exist to facilitate rapid encode/decode from our currency types and to provide a low-level NIO-focused API.

Currency types for expressing HTTP would not look like ours. They’d have different trade offs in their representation and API, perhaps preferring to maximally flatten or expand list headers as an example. While this is a worthy effort, simply extracting NIO’s types will not do a good job of achieving this goal.