title: When in my REST API should I use an envelope? If I use it in one place, should I always use it?
body: <p>I'm working on building a RESTful web service. I have read up on the principles of using HTTP for every mechanism as far as it will take you, and most of the time, like when fetching resources, it works pretty well.</p>
  
  <p>But when I need to POST a new entry of some sort, in the interest of clarity and robustness, no matter what the client may do, I want to offer the particular validation errors that the new entry may have failed at. Additionally, there are specific errors where, say, the data for creating a new user is perfectly valid, but a nickname or an email address may be taken. Simply returning <code>409 Conflict</code> doesn't finely enough detail which of the nickname or the email address was taken.</p>
  
  <p>So getting around this isn't rocket science: document a bunch of specific error codes and return an object with errors:</p>
  
  <pre><code>{ errors: [4, 8, 42] }
  </code></pre>
  
  <p>This means that in the case of unsuccessful requests, I'm not returning the resource or its key as I may be expected to by the REST philosophy. Similarly, when I return many resources, I have to frame them in some way in an array.</p>
  
  <p>So my question is: would I still be providing a well-behaved RESTful web service if I standardized an envelope to use for every request, such that, for example, there's always an object like <code>{ errors, isSuccessful, content }</code>? </p>
  
  <p>I have previously built RPC-style web services that used this, but I don't want to make something that's "almost REST". If there's going to be any point to being REST, I'd want to be as well-behaved as possible.</p>
  
  <p>If the answer is "hell no", which I think it may be, I would like to hear if it's at least solving the validation problem correctly, and what a good reference for this sort of problem solving might be, because most guides I've found have only detailed the simple cases.</p>