4

I am currently doing some research regarding validation (e.g. user-forms).

It is pretty obvious that validation absolutely has to be done on the backend to prevent "bad intentions" or malicious input etc.

Validation on the front end would additionally increase user friendliness as it is usually faster and we save a server roundtrip.

My question is the following: Is it good practice to do the validation e.g. only on the server-side and return localized error messages that are then shown by the front end?

Or is it an absolute no-go and validation should always happen on both sides?

And even if back- and frontend validation is done, and a failure happens on the backend due to an unexpected missing frontend validation, should the response contain a localized information to be shown on the frontend? Or would you just show a general "Something went wrong" message?

Somehow I have a bad feeling about localized error messages from an API.

JDC
  • 4,247
  • 5
  • 31
  • 74
  • Does this answer your question? [JavaScript: client-side vs. server-side validation](https://stackoverflow.com/questions/162159/javascript-client-side-vs-server-side-validation) – gmagno Sep 27 '20 at 22:19

1 Answers1

3

About your main question:

My question is the following: Is it good practice to do the validation e.g. only on the server-side and return localized error messages that are then shown by the front end?

As you said, front-end validation is good for friendliness but not only. Look at the example of validation of ZIP Code (it has fixed format, so it's easy to validate). If you don't validate at the front-end, you propably send many request to server (a little bit "overloading" server) and get response. It takes time. At the front-end, validation is do immediately. Additionally, about localizations: for web apps, for example in AngularJS, there are translation modules (in Angular there is angular-translate).

In parallel, the validation on the back-end is also good practice (no one wants to have bad data in database or crash the software).

I had a project using REST API with two people (I did a front-end in AngularJS, they - back-end in C#/.NET). I asked them for good messages about validation but unfortunately I got only "Bad request". For me as developer, it wasn't good during developing because I didn't know what that message mean (I didn't know whether it's a problem with my request or their bug). Moreover, I had to show message for the user: "Problem with form" (which is not friendly) - of course, I had also own validation.

Summary: it's better to have validation on both sides, moreover, the validation should inform user about problems in detail (but no so much).

jsDoggy
  • 46
  • 6
  • 1
    If I understand correctly you would not display the error messages from the backend in the frontend, but rather expect message that explain concisely what the error is about so that the frontend developers can handle it themselves, correct? So no localization for messages from the backend. – JDC Dec 14 '15 at 08:16
  • In most cases yes, no display backend messages in the frontend. – jsDoggy Dec 14 '15 at 21:42
  • 1
    It seems in your answer above @jsDoggy, you're saying the validation (frontend and backend) should inform the user concisely about any problems; but in your comment reply above this one, you're saying "no display" which I assume is don't display backend messages in the frontend. Can you clarify which among the 2 is your suggestion. – Andre Oct 04 '21 at 14:58