It would be great if API errors used the HTTP error response codes rather than returning 200.
Topic on Talk:Requests for comment/API roadmap
I see that we previously WONTFIXed this request but now that we're overhauling the API I think we should give it another look.
My reasoning in that bug still applies: an HTTP error indicates that something went wrong with the HTTP request, for example that the target resource wasn't found or couldn't be executed. As far as the API is concerned, that's the transport layer. If the API request is able to be processed but the result is an API error, that's reported at the application layer instead.
Say the API did return an HTTP 400 or 500 response code for an API error. How does the client determine that this is an API error rather than a varnish timeout or the like? I don't much like "blindly try to parse the body, if it succeeds it's an API error".
Also, say the API did return an HTTP 4xx response code for an API error. People would probably expect that action=delete would return a 404 if the target page isn't found to be deleted. But then what happens with action=query, when there may be multiple titles and some might be not found and others not? Or look at action=watch, before gerrit:53964 you could have made the case for it to return 404, but now it's like action=query.
I agree with Anomie's reasoning. An API error is not an HTTP error, and should not be reported as one.
If the error is related to application layer data, HTTP error codes are wrong, of course.
However IIRC the MWAPI emits server errors with HTTP 200 and a response that includes an error code like internal_api_error_ExceptionFooBar. Those are a server error, and should/could have a HTTP 50x code because the application failed while attempting to complete processing of the request, and all bets are off on what parts of the request were performed and committed to the database.
The current approach isnt _wrong_, as 50x are optional, but it worth reconsidering using them for the cases they actually apply to.