title: REST: Mapping application errors to HTTP Status codes
body: <p>Is it to be considered <strong>good practice</strong> to <strong>reuse RFC HTTP Status codes</strong> like this, or should we be <strong>making up new ones that map exactly</strong> to our specific error reasons?</p>
  <p>We're designing a web service API around a couple of legacy applications.</p>
  <p>In addition to JSON/XML data structures in the Response Body, we aim to return HTTP Status Codes that make sense to web caches <em>and</em> developers.</p>
  <p>But how do you go about mapping different classes of errors onto appropriate HTTP Status codes? Everyone on the team agrees on the following:</p>
  <blockquote>
  <p><strong>GET /package/1234</strong> returns <strong>404 Not Found</strong> if 1234 doesn't exist</p>
  <p><strong>GET /package/1234/next_checkpoint</strong> returns <strong>400 Bad Request</strong> if &quot;next_checkpoint&quot; <em>and</em> 1234 are valid to ask for but next_checkpont here doesn't make sense...</p>
  </blockquote>
  <p>and so on... but, in some cases, things needs to be more specific than just &quot;400&quot; - for example:</p>
  <blockquote>
  <p><strong>POST /dispatch/?for_package=1234</strong> returns <strong>412 Precondition Failed</strong> if /dispatch and package 1234 both exist, BUT 1234 isn't ready for dispatch just yet.</p>
  </blockquote>
  <hr />
  <p>(<em>Edit: <a href="https://www.rfc-editor.org/rfc/rfc2616#section-10" rel="nofollow noreferrer" title="RFC2616">Status codes in HTTP/1.1</a> and <a href="https://www.rfc-editor.org/rfc/rfc4918#section-11" rel="nofollow noreferrer" title="RFC4918">Status codes in WebDAV ext.</a></em>)</p>