Genericize ResponseProviding to an HTTPSRequester

[germ-mark]

Motivated by #3, which needs a URL request with different HTTP headers, genericize the ResponseProviding protocol to parametrize on more configurations of HTTPS requests.

The test bundle pulls in AsyncHTTPClient to demonstrate the drop-in use of their HTTPClient in place of URLSession, but it's intentionally omitted from the library dependencies as it pulls in a large set of dependencies.

[germ-mark]

Github actions throws an error about finding two targets for Vision Pro, so this unblocks the macOS tests from executing.

[germ-mark]

This is indeed very much like NIOHTTP1.HTTPRequest (an enum), but defined here to avoid adding library dependency on Swift NIO.

Source is
https://davedelong.com/blog/2020/06/27/http-in-swift-part-1/, where he argues the type is properly a struct not an enum.

[mattmassicotte]

I think I'm understanding what's changed here. And I think the additions in Sources/ATResolve/HTTPRequester.swift make sense. However! The only reason I introduced the ResponseProviding at all was specifically to keep the implementation usable for clients that do not have access to URLSession. One AsyncHTTPClient is pulled in, it no longer really serves a purpose.

So I'd like to propose a compromise between this and the original implementation.

GenericHTTPSComponents -> Request

public protocol ResponseProviding {
	func data(for request: Request) async throws -> Data
}

Please correct me if I'm wrong! But I think this will leave enough of an abstraction in place to work dependency-free with URLSession while also making what you need to do possible via a out-of-library conformance for the request stuff. Does that sound about right?

[germ-mark]

That sounds good, I can implement the proposed changes.

Are you concerned about AsyncHTTPClient as a test only dependency? I don't think, as configured, it impacts the ATResolve target. A little new to cross-platform, so acknowledge that it may not be desired in the test bundle either, or should be a separate bundle.

Can remove it as well, of course.

[mattmassicotte]

Unfortunately yes. Anything added to the package's dependencies array will be pulled into all clients, even if they are only used in tests. Hopefully one day SPM and/or Xcode get smarter about this.

I really hate sending things back period, and especially for this reason. But people are quite dependency-adverse, and this would be a pretty big impediment for many users.

[germ-mark]

understood. I'm learning from this so appreciate the feedback

[mattmassicotte]

Just wanted to clarify a pretty terrible typo on my end:

I really hate sending things back period

Back, not bad! I have a pretty strong bias towards just accepting submissions as long as they do not impact public API in a way I feel like I cannot support. I really appreciate your patience and work here! I might revisit the renaming as well potentially, to reduce churn. But regardless it was super cool of you to a) take this on and b) bare with me.

[germ-mark]

Thank you! No worries as I've been treating the PR's as worked proposals, so no attachment to the implementation short of we want to solve the problem in the most sensible way and not maintain a fork :).