Many current APIs are based on HTTP as their application protocol. Their response handling model is based on the assumption that requests either are successful or they fail. In both cases (success and failure) an HTTP status code is returned to convey either fact.
But API responses are more diverse. For example, there are cases where an underlying system returns a response with data that cannot be defined as a clear error. API providers who are integrating such a service might want to return a success response nonetheless, but returning an HTTP status code of e.g. 200 OK without any additional information is not the only possible approach in this case.
To make "soft error handling" easier for future API development we're currently trying to create an RFC for communicating warning information in HTTP APIs. I'd like to take the opportunity to discuss our current approach and maybe hear what others have tried in the past. The more use cases we know about, the more we can create something that fits all of them.
