fix: Fix parsing of the API response #850
Conversation
|
Appetize link: https://appetize.io/app/fhkk26vjmuaaaofrmfbtyq5bqa |
There was a problem hiding this comment.
I don't think this is the right approach, we shouldn't be putting non-generic code into the network service. Especially given that String is a Codable.
It also doesn't appear that we use the string response anywhere, in which case we shouldn't try to decode it as a String and attempt to use an empty response instead, so that endpoint can be changed to not send HTML in the future (as we always want parsable data from APIs)
@borisprimer I'll rework this while you're away.
| } | ||
| } | ||
|
|
||
| class SuccessResponseFactory: NetworkResponseFactory { |
There was a problem hiding this comment.
@NQuinn27 appreciate thoughts on naming here.
The idea is that this will always provide an empty success model because success is implicit based on a 200 code, and the actual response contents are ignored.
ImplicitSuccessResponseFactory or AutoSuccessResponseFactory maybe?
There was a problem hiding this comment.
Maybe ImplicitSuccessResponseFactory is best, but I dont have very strong feelings
Sources/PrimerSDK/Classes/Services/Network/PrimerAPIClient.swift
Outdated
Show resolved
Hide resolved
This PR fixes a parsing problem for the only case where we have a pure string as a response (HTML). This is mostly for @jnewc since you were working on the API layer refactor. Make sure I did everything as you would do it and feel free to change the implementation if you don't like it.
We are currently waiting for confirmation from Lime that this is working (they are testing from the branch), if we get it while I am away, please make a new release with this fix.
Thanks!
PS: If you need more context, please ping Semir.