Very interesting. Are you the author?

I agree and I updated the post with information about using a 405 (Method Not Allowed) for situations where the method is available but not for the resource being requested.

I updated the post with your suggestion. Thanks!

My approach has been to combine semantic HTTP status codes with fine-grained, specific application error codes. The status codes give a general idea as to what went wrong, while the application error codes (represented as a code/field pair) point to what went wrong and the specific JSON field that needs to be corrected. This has made it really easy to write clients that tell the user a lot more than “your request is bad and you should feel bad.”

But I think you possibly make or promulgate a misunderstanding of 501 here.

> Instead, either reply with a 404 but using a body that your caller can understand (JSON or whatever MIME type you’re accepting) or, even better, reply with a 501 (Not Implemented). According to the HTTP definition this “the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource”.

In the HTTP spec, “method”, means an _http method_, like GET, POST, (the new proposed) PATCH, etc. And even the quote says “not capable of supporting it for _any resource_”.

Ie, if your app does not support PATCH _at all_, then, sure, returning 501 is the right thing to do.

If your server doesn’t support POST to this specific URL? Nope, not 501. Let alone if your not-entirely-REST API supports /api?command=send but not /api?command=selfdestruct — definitely not 501.

I am not sure if you intended it this way, but a casual reading of this post could give you the wrong idea about 501, it is suitable for use only in very specific circumstances, most ‘the api call you made is not understood’ errors really are going to be 404s (but, sure, with an appropriate json/xml/whatever with machine readable details, that’s be great).