Conversation
Remove JSON Remove commented out lines Add check for status code Update streaming and Body for new API Attach request to response Move handle invocation to be a closure Update nio-http name Update import statements Remove extra tests from AllTests
Create a MutableRequest that can vend the (immutable) HTTPClient.Request Move templating and queryparam logic into MutableRequest
|
FYI @artemredkin @weissi |
|
awesome! |
|
@ianpartridge @weissi This currently builds against I'd be inclined to do the former, as updating to newer releases of the client should be straightforward. However, we do expose the |
|
@djones6 I think that is sensible. I would like if we tried to slow down the breakages but I can understand if you want to |
Remove obsolete swift 4 Package
| /// request.headerParameters = HTTPHeaders([("Cookie", "v1")]) | ||
| /// ``` | ||
| public var headerParameters: [String: String] { | ||
| public var headerParameters: HTTPHeaders { |
There was a problem hiding this comment.
Provide existing API with mapping to HTTPHeaders
| completionHandler(dataResponse) | ||
| return | ||
| } | ||
| completionHandler: @escaping (Result<RestResponse<Data>, Error>) -> Void) { |
There was a problem hiding this comment.
Make result return RestError rather than generic Error
Move structs to own source files
|
@ianpartridge Example of changes required to KituraKit to adopt the new API: Kitura/KituraKit@53ea6e2 |
|
@djones6 btw, beta 4 landed earlier. It should be API compatible with beta 3, although there are some deprecations (with very straightforward fixes) |
This PR re-implements the SwiftyRequest API on top of the Swift-NIO based
async-http-client, and adds client certificate support.This is based on work done by @Andrew-Lees11 described in #58, including:
CodableHTTPMethod.swift has been removed and replaced with theNIOHTTP1.HTTPMethodHTTPMethodremains, and is now convertible to/fromNIOHTTP1.HTTPMethod.headerParametershas changed from a[String:String]toHTTPHeadersheaderParametersremains[String:String]with mapping under the coversResult<HTTPClient.Response, RestError>instead of(Data?, HTTPURLResponse?, Error?)RestResponsenow represents anHTTPClient.Responsethat is generic over the body instead of anHTTPURLResponsewith the result of the body.Credentialsinput has been converted to be an extensible struct.RestErrornow represents any error that could be returned from a request attempt, including errors relating to malformed URLs orHTTPClientErrors. So strictly speaking, it's not just a REST error, but I'd prefer to retain the naming.RestErrornow has a convenience function for retrieving the response body data when the error represents an unsuccessful request.RestRequest.initparametercontainsSelfSignedCerthas been renamed toinsecureto more accurately reflect what it means, though I've retained (and deprecated) the current naming.In addition, I have implemented Client Certificate support for 2-way SSL. This is non-functional in SwiftyRequest 2.x. This initial support provides a convenience API for consuming a certificate (and its private key) from a PEM-formatted file,
String,Dataor[UInt8]. There is also support for supplying the rawNIOSSLCertificateandNIOSSLPrivateKeywhich allows complete freedom of the data sources, if required. We could add additional convenience APIs for other popular file formats in the future.As well as refactoring the existing tests for the new API, I've added a Client Certificate test that downloads a valid certificate from https://badssl.com/download/ and then presents it to https://client.badssl.com. The certificate must be downloaded by the test because it may be reissued as it expires. The password for the certificate's key is hard-coded into the test - I'm assuming that it will not change over time.
Effect of breaking API changes
Kitura/KituraKit#53 demonstrates the extent of changes required to an application to migrate to the new API.
Motivation and Context
Resolves #58 and #57