I'm a rails developer, and have noticed that while defining validations I find myself confused about the scope I'm trying to cover.
For example, I have basic cases where a field of data (ex: name, email, etc) needs to be present, or the correct size, format, etc.
These cases are easily handled by existing Rails validations.
But I have other cases where dependent data is required or certain combinations of data are allowed/not allowed.
In these cases I could write custom validations. However, a "user" of the application should not be exposed to a UI that could allow those types of errors.
That said, my software does have an API and if a developer does not use the API properly, he could allow for bad data if I don't add some kind of constraints to the system, be they validations or Exceptions/Errors or something else.
My thinking is... validations have pretty messages for users. Developers don't need those. Exceptions/Errors on the other hand have messages too, but they tend to be more developer oriented.
So is there a "best practices" way of thinking and approaching issues like this that could help me better organize my code so it's "easier" to extend, and separates concerns in an intuitive (or at least generally agreed upon) way?