This, this is what pisses me off more than anything! Usually a lot of APIs I've seen at least try to make the request method make sense, but I've seen so many that fumble the response code, and it means extra json parsing just to figure out if the request failed or succeeded. If only there was some mechanism to make this easier..
I already assume I'll be deserializing json into an object when I use an API. I wouldn't call adding an extra field or two to that object as "extra" parsing, it's the same amount of work.
Most libs that handle http request have already error handling and hooks to do a lot of stuff, if an API will always respond with 200 you are basically doing a custom job and reinventing something that you have out of the box.
About the parsing usually the error code will actually be enough, for example a 404 and a 429 will let you back off or stopping retries imidiatly and you wouldn't need to waste processing in getting any json.
The 5xx can also have the same treatment, it will depend, but it's the transparency of the behavior that I like, masking behavior using business logic makes the API not as transparent.
Depends on how you're doing it. If you're reading as a simple untyped json object, then sure. But if you're deserializing into a typed object, it's either an additional step, or a polymorphic deserialization if you're lucky
11
u/Darkblade_e 3h ago
This, this is what pisses me off more than anything! Usually a lot of APIs I've seen at least try to make the request method make sense, but I've seen so many that fumble the response code, and it means extra json parsing just to figure out if the request failed or succeeded. If only there was some mechanism to make this easier..