Input Validation

Little Bobby Tables might not be real, but SQL injection certainly is. And there are lots of ways to prevent it. And we should do all of them. From sanitizing inputs as soon as possible to using least privilege when making changes (why does the student management interface even have drop table permission?).

But this isn't about what to do. This is about where to do it. And I'm going to assert that it's as soon as possible. Because the sooner you can tell the user, the more context you can provide. Which would you rather deal with, a website that lets you type in answers to all 15 fields, then comes back with "Invalid input, please re-submit" or one that, as soon as you leave the age field, tells you that the input can only be numbers if you hit a character by mistake? I know which one I'd choose.

The same thing applies to client libraries that you might provide for your service. Very often there are options that can't be chosen together. Save time, a server round-trip, and all of the error generation/parsing by doing that on the client.

Yes, sometimes this means making a library that you can re-use both client and server-side. Or it might mean implementing the validation in multiple languages because you've got multiple clients. But it still makes sense.  You always want to delight your users.

Even (especially?) when they make mistakes.