over at Applying the Web to Enterprise IT
, there is an interesting opinion about what a 4xx Client Error means. it is stated in a follow-up piece to one that claims that REST doesn't lie, and it says the following:
HTTP is actually quite clear on how decoupled the server is from the client by calling all non-technical errors simply Client Errors. Dang! So simple! 404 – who broke the contract? The client! 406 – who broke the contract? The client! …
i don't think it appropriate to phrase it like it's the client who necessarily did something wrong when, for example, a 404 is returned. if you follow a URI that was supposed to be persistent and you get a 404 because the server did something wrong, it's quite a stretch to argue that it's your fault
. it's pretty clearly not.
i think it is much more appropriate to think about 4xx codes in terms of who has to deal with them. if you get a 5xx, there really isn't much you can do. if you get a 4xx, you should have some strategy how to deal with that, even though the condition itself might very well have been caused by the server.
i guess for some 4xx this is actually quite obvious: you get a 401 and it might be a good idea to try some credentials if you have any; you get a 405 and you might try another method; you get a 406 and you might to try to ask for a different representation; you get a 408 and you really should be a bit faster next time.
like so many other things in REST (i am still curious to find out more about REST Linguistics), this is interestingly close to real life: if something goes wrong, it is not very productive to argue about who did something wrong; it is much more effective to decide who should start trying to improve the situation. HTTP error codes simply tell you which side should act to try to get things working again.
Comments