Fixed multipart sender

FIX: allow to send multipart with any method

closes #11

SPM support and some improvements

• switched to Swift version of Reachability
• implemented SPM support
• desiredStatusCode deprecated (but still works), use successStatusCode instead
• custom errors improvements

Now you could set more than one successStatusCode as well as set more than one statusCode for custom errors.

⚡️Implement WebSockets support 🎉

1.10.0

⚡️Implement WebSockets support 🎉

Implement plain String response decoding 🙂

1.9.0

Implement plain String response decoding

Support custom coding keys! 🎉

Use DictionaryEncoder for headers, so now you could define your custom coding keys e.g. like this

struct Headers: Codable {
        var platform: String?
        var sdk: String?
        var version: String?
        var id: String?
        
        enum CodingKeys: String, CodingKey {
            case platform = "X-Mobile-Platform"
            case sdk = "X-Mobile-SDK"
            case version = "X-Mobile-A"
            case id = "X-Mobile-ID"
        }
    }

Use DictionaryEncoder for multipart
Implement FormURLEncodedPayload protocol and sendFormURLEncoded method
Conform PayloadProtocol to just Encodable
Conform ResultType to just Decodable
Rename buildQuery(_) into buildURLEncodedString(from:)
Improve error messages printing, now use Logger instead of just printing
Update Example project to demonstrate custom coding keys for headers
Update readme, add info

NetworkError: implement optional raw `Data`

So now you're also able to parse error response data if needed

.onError { error in
    switch error.code {
    case .notFound: print("It's not found :(")
    default:
        print("Another error happened: " + error.description)
        if let raw = error.raw, let rawResponse = String(data: raw, encoding: .utf8) {
            print("Raw response: " + rawResponse)
        }
    }
}

APIRequest with custom server URL

Now you can set custom server url for each request 🙀

let server1 = ServerURL(base: "https://server1.com", path: "v1")
let server2 = ServerURL(base: "https://server2.com", path: "v1")
let server3 = ServerURL(base: "https://server3.com")

APIRequests with custom server url will look like this 🔥

APIRequest(server1, "endpoint", payload: payloadObject)
APIRequest(server2, "endpoint", payload: payloadObject)
APIRequest(server3, "endpoint", payload: payloadObject)

And in some cases you even can do it like this 😏

APIRequest("endpoint", payload: payloadObject).serverURL(server1)

Implement Flatten and Chained 🚀

Chained requests

Now you're able to run up to 10 requests one-by-one!

API.employee.all()
    .and(API.office.all())
    .and(API.car.all())
    .and(API.event.all())
    .and(API.post.all())
    .onError { error in
        print(error.description)
    }.onSuccess { employees, offices, cars, events, posts in
   // do what you want with received results!!! 🍻
}

onRequestStarted, onNetworkUnavailable, onCancellation, onNotAuthorized, onTimeout also available!
//TBD: onProgress

It is awesome! Especially for whom who not familiar or don't like reactive programming 🙂

Flatten

And if you want to run several requests one-by-one or concurrently but with just completion handler you also can do that with .flatten()

[API.employee.all(), API.office.all(), API.car.all()].flatten().onError {
    print(error.description)
}.onSuccess {
    print("flatten finished!")
}

to run them concurrently just add .concurrent(by: 3) to run by 3 at the same time
to skip errors also add .avoidCancelOnError()
to get progress add .onProgress

Hope it's cool! 😎
Please let me know in issues if you need any improvements or bug fixes.

🚧 Errors logic refactoring

Removed Int error handlers. Use NetworkError everywhere instead.
HTTPStatusCode is deprecated, renamed to StatusCode instead
KnownNetworkError is deprecated, renamed to NetworkError
onKnownError is deprecated, use just OnError
CodyFire.shared.knownErrors now has internal protection, use setters instead

Rename `EmptyResponse` into `Nothing` 😏

To achieve APIRequest<Nothing> instead of APIRequestWithoutResult, but it's still available.