Closed Pomanks closed 2 years ago
The optional variant was removed in v1.0 to avoid "polluting" the API – this feature is rarely needed. I think it should be possible to implement it without introducing new public methods. It's something worth exploring. PRs are welcome.
A potential solution would be to treat the empty response as an error, even if the status code is not… The implementation is not public and only located in the delegate:
func client(_ client: APIClient, validateResponse response: HTTPURLResponse, data: Data, task: URLSessionTask) throws {
guard (200..<300).contains(response.statusCode) else {
throw APIError.unacceptableStatusCode(response.statusCode)
}
if response.statusCode == 204, data.isEmpty {
throw APIError.emptyResponse(response.statusCode)
}
}
It would then be up to the developer to handle such a case.
I understand the rarity of this response but I feel it's something than needs to be available up front instead of something handled like an issue (which it isn't).
What are your thoughts?
That's a good idea. It will allow the developers to cover this scenario. I think that's what Alamofire does by default as well.
But I'm not sure throwing an error is an ideal option. It'll be nice to allow developers to use optionals and consider this scenario a successful completion. I was thinking something like this:
protocol OptionalProtocol {}
extension Optional: OptionalProtocol {}
func decodeResponse<T: Decodable>(_ type: T.Type) {
print(type is OptionalProtocol.Type)
}
It's not indeed, I just didn't see any other option at the time 😅 I get it now.
I'll make a PR 👍🏻
Here you go: Pull Request #58
Hi 👋🏻
When declaring a method with an optional response body (see example), the call only results in a decoding error because the method tries to decode an empty response.
Optional response body method:
Error:
The same code worked in previous version though (it simply returned
nil
).