Moya: How can I override parameterEncoding?

[jk]

I've some trouble modifying the parameterEncoing defined in the Moya class since it's not part of the MoyaTarget protocol definition. For some endpoints I need to POST data as .JSON, not the default .URL.

Sadly the Demo App doesn't cover it in GitHubAPI class.

Can somebody give me hint or should it also be part of MoyaTarget and nobody hasn't the need to change that until now?

Update 1
I've something like the following in my MoyaTarget extension:

extension MyAPI : MoyaTarget {
    // …
    // public var path: String {…}
    // public var parameters: [String: AnyObject] {…}
    // …
    public var parameterEncoding: Moya.ParameterEncoding {
        switch self {
        case .Search(_):
            println("parameterEncoding for .Search: JSON")
            return .JSON
        default:
            println("default parameterEncoding: URL")
            return .URL
        }
    }
    // …
}

[jk]

Found the solution by myself. I had a hard time with the docs.

I had to replace the following line

let MyAPI: MoyaProvider<MyAPI> = MoyaProvider<MyAPI>()

where I used the default initializer, with the following:

let MyAPI: MoyaProvider<MyAPI> = MoyaProvider<MyAPI>(endpointClosure: {
    (target: MyAPI) -> Endpoint<MyAPI> in

    return Endpoint(URL: url(target), sampleResponse: .Success(200, {target.sampleData}), method: target.method, parameters: target.parameters, parameterEncoding: target.parameterEncoding)
})

where I set the endpointClosure. Within the the closure I defined my Endpoint with my own parameterEncoding: (parameterEncoding: target.parameterEncoding).

Hopefully this issue helps future like-me's :)

[ashfurrow]

@jk I'm glad you found the solution! Do you have any suggestions to improve the docs?

[jk]

@ashfurrow I'm already thinking about it, but it needs some more thoughts. In general I would shoot for more complete examples. Newcomers as I am one, lack guidance. For example it wasn't quite clear at first for me if I have to implement my own Provider. Turns out it was sufficient to use the default one with a closure as an initialization parameter.

[ashfurrow]

Cool, I've opened #189 – let's collect all the suggestions, ideas, and feedback there :tada:

[Neirys]

Hi, sorry for commenting closed issue. I spent last hour troubleshooting an Error Domain=NSURLErrorDomain Code=-1017 "cannot parse response".

Due to non-optional parameter property in MoyaTarget protocol, setting endpoint's parameter encoding to .JSON causes the associated NSURLRequest to have an empty HTTPBody property instead of a nil one. It seems that some server-side technology can have bad time handling such configurations (I'm using Node.js/Express.js as a sandox server).

Moreover, it's more likely that parameter encoding are request-basis instead of global-basis (usually .URL for .GET methods and .JSON for .POST | PUT methods).

Could be a good idea to make parameterEncoding part of the MoyaTarget ?

[ashfurrow]

No problem :) It's possible to specify parameter encoding on a per-target basis through the endpoint resolver closure. You can use the endpointByAddingParameterEncoding function on Endpoint to help. Form there, if you really need a nil body instead of an empty one (though I'm not sure there's a semantic difference...) you can use the URL encoding, or otherwise.

Does that answer your question?

[Neirys]

@ashfurrow Thanks for your quick reply :) Actually I already had some solutions in mind but I was wondering if some changes on Moya could reduce possibilities of server-side errors like I had today.
Two idea in mind : making parameterEncoding as part of MoyaTarget protocol or maybe changing the MoyaTarget's parameters property to an optional.
Big inconvenience to these solutions : they don't support backward compatibility to previous versions :(

[ashfurrow]

We've got a breaking-changes release coming up, so it's a good time to get these in.

Alamofire has default nil parameters – I think we should change to reflect their behaviour. Alamofire already handles parameter encoding – it only uses URL parameter encoding if the request _can_ encode parameters in the URL, so that's work we don't have to do. Since we already require users to specify the HTTP verb on the target, I think that's sufficient.

Does that make sense?

[Neirys]

Totally makes sense !

[ashfurrow]

@Neirys I've opened #226 that you can subscribe to to be notified when it's finished. Or take a stab at it yourself!

[wishsoul]

jk's solution works for me! 👍 👍 👍