Please use HTTP error code 400 for bad API requests

[lloydjatkinson]

Hi!

Please consider returning HTTP 400 for bad API requests. Currently, 200 OK is used for both valid and invalid API requests.

What problem does this solve?

Using a more appropriate error code allows for code consuming the API to be cleaner. Currently, the developer needs to check the success property of the JSON response. If a 400 is used, this will no longer be the case.

How will this help consumers of the API?

Usually, HTTP libraries are response-data agnostic and rely solely on the server returning an appropriate status code. Take for example, axios.js:

try {
    const response = await axios.get('https://data.fixer.io/api/2013-03-16?access_key=<some bad key>');
    if (response.success) {
        performSomeAction(...);
    } else {
        performSomeErrorAction(...);
    }
} catch () {
    performSomeErrorAction(...);
}

Because the API will currently not respond with a 400, it is necessary to conditionally check success. Furthermore, another call to performSomeErrorAction(...) is present in the catch to handle other network/request problems.

However, if the API responded with a 400 for bad requests the code could be simplified by making using of the single catch:

try {
    const response = await axios.get('https://data.fixer.io/api/2013-03-16?access_key=...');
    performSomeAction(...);
} catch () {
    performSomeErrorAction(...);
}

While this is a Javascript example, the same problem arises in HTTP libraries for various other languages, because of the expectation that HTTP error codes will be used.

Will this be a breaking change for existing consumers of the API?
As far as I see it, no. The success property can still be present meaning that current consumers will not notice any difference, and new consumers can make use of HTTP error codes.

I hope I've been able to explain the issue well.
Is this something that you might consider adding to the API?

Thanks,
Lloyd

[julian-zehetmayr]

Hi Lloyd,

Thank you for your comment. We will definitely consider adding HTTP status codes for the error responses, and I will keep you posted on this here.

[lloydjatkinson]

Has the API been updated to fix this then?