IT MAKES THE FORM PLEASANT. IT STOPS NOTHING, because the request can be made WITHOUT YOUR PAGE AT ALL. Module 11 is the consequence.
This is a free preview lesson because it is the sentence somebody should read before deciding this course is about drag and drop.
THE MECHANISM IS PLAIN AND NOT A SECRET. Your page calls an endpoint. The endpoint is visible in the browser's own network tab, on the page the user is looking at. Anybody who can open that page can see the URL, the shape of the body, and the credential the browser is sending — and can send their own request.
SO EVERY CHECK IN YOUR FORM IS SOMETHING THAT HAPPENS BEFORE A REQUEST YOUR APPLICATION CHOOSES TO MAKE. Skip the page, and the checks never ran — not because they failed, but because they were never in the path.
WHICH IS NOT AN ARGUMENT AGAINST THEM. A form with no client-side validation is genuinely unpleasant: every mistake costs a round trip, and errors arrive one at a time from a server that stops at the first. They are the right way to be kind to the person filling the form in.
THE ARGUMENT IS ABOUT WHAT THEY ARE FOR. They are a courtesy to a cooperating user. They are not a constraint on the data, and treating them as one is how a database acquires rows that no screen in the application could have produced.
AND THE FAILURE IS INVISIBLE TO EVERY FORM OF TESTING THAT USES THE APPLICATION. Every path through your pages applies the rule perfectly. Testing harder will never find it, because the test is the one thing that goes through the page — which is why the check is a question rather than a test: what happens if somebody calls the endpoint directly?
THE ANSWER SHOULD BE THAT THE RULE IS APPLIED ANYWAY, BY A BUSINESS OBJECT RULE OR BY THE TARGET SYSTEM. When it is, your form validation is doing exactly the job it should. When it is not, the rule does not exist — and nothing on screen will ever tell you.