title: Returning Errors in Web API
body: <p>I'm developing a brand new REST API using ASP.NET Web API. Coming from a WCF background, I feel drawn to creating "error contracts" for my API.</p>
  
  <p>In this case, I'm not talking about unhandled exceptions being returned to the client. Instead, I'm focusing on errors such as the API being used improperly by the client - especially those where the client can automatically create these errors and resubmit the requests.</p>
  
  <p>Most examples I've found just have a string being returned, usually by throwing an HttpResponseException, or at least doing some stuff to make the process of building up an informative error string more automated: <a href="https://stackoverflow.com/questions/16243021/return-custom-error-objects-in-web-api">Return custom error objects in Web API</a></p>
  
  <p>I'm thinking about instead creating an HttpResponseException, passing in an HttpResponseMessage whose content is set to my specific error contract type.</p>
  
  <p>My API is also making heavy use of automatic model validation, though, and those model validation errors come back as a totally different structure.</p>
  
  <p>So should I force my "errors" into the same format as the model validation responses? What are the best practices here?</p>
  
  <p>Lastly, my API will expose formatting options of json, xml, and protocol buffers. As a result, I really need to make sure that my strategy is formatter-independent.</p>