[proposal] Extract setting up an URLRequest into a separate library

[Ralf Ebert]

I'd like to propose a structural refactoring of TinyNetworking.

It's a bit daring but I am using it already in one of my projects and I thought I'd write it up and share it with you. Maybe its helpful to you or not; in any case I'd be grateful for feedback about the idea.

My starting point was that while I'm excited about the Endpoint abstraction that TinyNetworking provides, I am not a fan of these very-many-parameters initializers like:

public init(_ method: Method, url: URL, accept: ContentType? = nil, contentType: ContentType? = nil, body: Data? = nil, headers: [String:String] = [:], expectedStatusCode: @escaping (Int) -> Bool = expected200to300, timeOutInterval: TimeInterval = 10, query: [String:String] = [:], parse: @escaping (Data?, URLResponse?) -> Result<A, Error>) {
   ...
}

I think TinyNetworking does two things at once here: a) providing the endpoint abstraction (URLRequest+how to validate/parse the response) and b) provide convenience to setup the URLRequest.

I suggest to separate out the code to setup a URLRequest conveniently into a separate tiny library which TinyNetworking could depend on/re-export (or maybe not).

This simplifies the Endpoint abstraction a lot. It's a tiny bit more to write because you always need to create an URLRequest but overall for me this feels a lot more clean and tiny.

I did a fork with a prototype implementation here:
https://github.com/ralfebert/tiny-networking/commits/urlrequest
https://github.com/ralfebert/sweeturlrequest

This could be backward-compatible, but I wanted to do a rough sketch at first. Here is an example what the usage of the URLRequest-only-based API could look like compared to what it looks like now.

I also extended Endpoint a bit to model the status code validation more generically as 'validate' function.

What do you think about such a separation?

[Chris Eidhof]

Hey Ralf,

Thank you! I don't think this is such a good idea, mainly because it adds complication. I don't really see the benefit for users of tiny networking. In addition, it will make maintaining things more complicated, as we need to ship two libraries and keep them in sync.

I'm absolutely fine with you forking the library and making these changes (under a different name). But I'd like to keep tiny-networking a single self-contained library.

Closing the issue (just so it's out of the open issues list). Of course happy to discuss.