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?

closed as primarily opinion-based by Robert Harvey, GlenH7, durron597, Ixrec, user40980 Jul 29 '15 at 13:10

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I do not exactly understand your problem. Anyway: The ActiveRecord validations main goal is to actually ensure data integrity. It doesn't matter where the data comes from, it's on the model level, so part of the business rules. Also what's the difference between 'validating user input' and 'ensure data integrity'? You validate user input to ensure data integrity. (Data integrity being a bit of a broad term, meaning basically 'valid data'). What additional 'features' does your API have that are different from the normal user input? – thorsten müller Jul 28 '15 at 13:49
  • @thorstenmüller Well that is the question, so seems you understand it fine. The issue is that with user input, the cases I need to account for are fairly limited. If on the other had I extend validations to cover the external API... then the internal API, then just general constraints to avoid developer errors.. the number of cases will be nearly infinite. I'm trying to understand what the best way to approach this area of programming is. – Nathan Jul 28 '15 at 13:53
  • Why does it seem wrong? Certainly it might be redundant, if the API already provides its own validation. Check the API documentation. – Robert Harvey Jul 28 '15 at 14:00
  • Adding another comment to answer your last question more directly. My data model has cases where dependencies exist (ex: some data must exist before other data). Also, my data model has cases where certain combinations are invalid. The API does not restrict the developer around these areas... and instead assumes he will build a UI that will prevent incorrect user error. – Nathan Jul 28 '15 at 14:01
  • @RobertHarvey what API documentation? I'm writing the API. – Nathan Jul 28 '15 at 14:01

Browse other questions tagged or ask your own question.