There is always a tension in programming between creating something that is hard to misuse but at the same time adheres to standards to try and leverage the Principle of Least Surprise. One area I personally struggle with this conflict is how to communicate to a client (of the software kind) that they have made a request for something which doesnâ€™t currently exist, and almost certainly will never exist.
As a general rule when someone requests a resource that doesnâ€™t exist then you should return a 404 (Not Found). And this makes perfect sense when weâ€™re in production and all the bugs have been ironed but during development when weâ€™re still exploring the API itâ€™s all too easy to make a silly mistake and not realise that itâ€™s due to a bug in our code.
An Easy Mistake
Imagine youâ€™re looking up all orders for a customer, you might design your API something like this:
For a starter you have the whole singular noun vs plural debate which means youâ€™ll almost definitely try this by accident:
or make the inverse mistake
By the standard HTTP rules you should return a 404 as the resource does not exist at that address. But does it actually help your fellow developers to stick to the letter of the law?
What makes this whole issue much thornier is that if you decide you want to do the right thing by your fellow programmers you will likely have to fight any web framework youâ€™re using because they usually take the moral high ground and do what the standard says.
What then ensues is a fight between the developer and framework as they try their hardest to coerce the framework to send all unmatched routes through to a handler that can return their preferred non-404 choice.
A colleague who is also up for the good fight recently tried to convince the Nancy .Net framework to match the equivalent of â€œ/.*â€ (the lowest weighted expression) only to find they had to define one route for each possible list of segments, i.e. â€œ/.*â€, â€œ/.*/.*â€, â€œ/.*/.*/.*â€, etc. .
Even then he still got some inconsistent behaviour. Frameworks also make it really easy to route based on value types which gives you a form of validation. For example if I know my customer ID is always an integer I could express my route like this:
Thatâ€™s great for me but when someone using my API accidentally formats a URL wrong and puts the wrong type of value for the ID, say the customerâ€™s name, they get a 404 because no route matches a non-integer ID. I think this is a validation error and should probably be a 400 (Bad Request) as itâ€™s a client programmer bug, but the framework has caused it to surface in a way thatâ€™s no different to a completely invalid route.
Choice of Status Code
So, assuming we want to return something other than Not Found for what is clearly a mistake on the clientâ€™s part, what are our choices?
In the debates Iâ€™ve seen on this 400 (Bad Request) seems like a popular choice as the request, while perhaps not technically malformed, is often synonymous with â€œclient screwed upâ€. I also like Phil Parkerâ€™s suggestion of using 405 (Method Not Allowed) because it feels like less abuse of the 4XX status codes and is also perhaps not as common as a 400 so shows up a bit more.
 According to this StackOverflow post it used to be possible, maybe our Google fu was letting us down.