When interacting with RESTful web services, there’s a depressingly common anti-pattern: always return status 200 OK, but embed a more meaningful status code in the body of the response. Frequently, the embedded status code is just the HTTP status code you should have returned in the first place.
This “fixes” situations where you have badly behaving clients that don’t do proper error handling, but also breaks the entire point of doing REST.
Alice works on an app that, while most of the time the code is decent, has a service that does this. This service also does something even worse: depending on the URL parameters you pass to the query, it may do something like this when it returns errors:
{ "statusCode": 422, "errors": { "Value should be an integer": [ "version" ] }}Or something like this:
{ "statusCode": 422, "errors": { "orderSatus": [ "The value you selected is not a valid choice." ] }}Sometimes, the service returns errors in the form “error message: [list of fields]”, and sometimes it returns errors in the form “field: [list of errors]”. I’d argue that the latter is more correct, but either is workable if they were at least consistent.
At first, looking at the responses, I assumed this was some multi-team, microservice situation where you had specification drift and two different teams solving the same problem slightly differently, but no: it’s just one service, maintained by one small team.
These kinds of inconsistencies abound in the codebase. The entire thing is designed to make the front-end team pull their hair out, and any third parties consuming the API to go completely insane.
Alice writes: “I’m glad I only maintain the back-end and front-end is someone else’s job.”
Alice says that, but she clearly has her work cut out for her, too, if this is going to get any better.
Post a Comment