What is the suitable HTTP status code when request is successful but has warning messages?

Question

In proper usage of REST, what is suitable the HTTP status code when request is successful but has warning messages?

In our case; clients are web applications running on browsers. We prefer status codes as following:

• HTTP 200, 201, 204 when request processed successfully
• HTTP 422 when request violates some business rules
• HTTP 500 when unexpected exceptions are occured while processing request

But we couldn't determine which status code should be used when request processed successfully but some information or warning messages need to send to client?

Answer 1

In the HTTP protocol there actually is a "warning" header (see Header Field Definitions ). These are HTTP warnings, but you could use code 199 to send what you need:

199 Miscellaneous warning The warning text MAY include arbitrary information to be presented to a human user, or logged.

The problem here is the next bit of specification:

A system receiving this warning MUST NOT take any automated action, besides presenting the warning to the user.

Because of this, I think you're better off adding data about the warning in the response content (and keep using the 200 status code).

Answer 2

HTTP status codes are determine whether the request has been proceed properly or not and there is no warning status. If you want to provide information about result of your internal functions you should add information status to the response content eg:

{
    status: "WARNING",
    code: "WARNING-CODE"
}

Answer 3

In a similar case I used HTTP 418 (see HTCPCP)

The clients were web apps using the Google Maps API to display map tiles. And I wanted to make a distinction between a deliberately blank tile (zero data -> blank tile with HTTP 200) and a blank tile resulting from missing data (null data -> blank tile with HTTP 418).

Returning a 404 precluded me from sending a tile in a response body, and would place ugly symbols on the map. But returning a 418 still allows a response body (perhaps due to lack of serious standards definitions surrounding HTTP 418?), AND at the same time provided a status code that I could easily filter in the logs, etc. to use for diagnostic purposes.