Changes made in #257 introduces a BC break
phansys opened this issue · comments
Changes made in #257 introduces a BC break in the return value of AbstractApi::get().
Prior to these changes, if the response body was empty, get() was returning false, and currently it returns null.
Since this package lacks a exception oriented flow in front of HTTP responses ending in error codes (400~599), my implementation relies in the return values to determine the situation about a request.
Obviously the compatibility with PSR-18 is great, I'd just like to expose this situation in order to verify if these changes could respect BC.
Note that this is the only one BC break I've checked, since this is the first issue I encountered after updating the dependency.
@phansys Thank you for your finding and your PR. The issue seems valid and I'll look into this.
A note about the missing exceptions for HTTP status codes.
Since this package lacks a exception oriented flow in front of HTTP responses ending in error codes (400~599), my implementation relies in the return values to determine the situation about a request.
I would recommend to always check the HTTP response code instead of exceptions. You can use $client->getLastResponseStatusCode().
This is also the recommended way in PSR-18, see https://www.php-fig.org/psr/psr-18/meta/
Throwing exceptions for 4xx and 5xx responses
The initial idea was to allow the client to be configured to throw exceptions for responses with HTTP status 4xx and 5xx. That approach is not desired because consuming libraries would have to check for 4xx and 5xx responses twice: first, by verifying the status code on the response, and second by catching potential exceptions.
To make the specification more predictable, it was decided that HTTP clients never will throw exceptions for 4xx and 5xx responses.
I just released v1.8.1
Thank you for your contribution.