|
| 1 | +# Server-side Validation |
| 2 | +Your API can handle different types of requests now. But does it validate the request data before processing it? The objectives of this lesson are: |
| 3 | +1. Understanding the need for server-side validation |
| 4 | +2. Getting familiar with implementing server-side validation |
| 5 | + |
| 6 | +## What is Validation? |
| 7 | +Validation can mean a lot of things, but in API land it generally means figuring out if the data being sent to the API is any good or not. Validation can happen both on client-side before sending the request or on server-side when receiving the request. Client-side validation is generally used to provide quick feedback to a user. For example, when you're submitting a form and you see a field highlighted in red saying "Required field". Basically the client validated that the field cannot be empty. However, an API must not entirely rely on client-side validation. We have talked about how the frontend need not know the underlying implementation of an API. Similarly, an API does not know what actually happened on the frontend when it receives a request from a client. That is why more often than not, the first step in processing a request is to validate the data that came with it. |
| 8 | + |
| 9 | +There might also be scenarios where the frontend cannot perform the validation. Consider this example: The API receives a signup request with an email ID. In case it turns out that this email ID was already used with a previous user account, it could cause issues if the new signup request is processed. So the API must first validate the email ID from the user database and inform the client accordingly. The frontend has no way by itself to check if the email ID was used in a previous user account. |
| 10 | + |
| 11 | +Validation ensures that your API performs optimally irrespective of what kind of requests it receives. |
| 12 | + |
| 13 | +### Types of Validation |
| 14 | +1. **required**: Specifies whether a data parameter needs to be provided before the request can be processed. |
| 15 | +2. **minlength and maxlength**: Specifies the minimum and maximum length of textual data parameters. |
| 16 | +3. **min and max**: Specifies the minimum and maximum values of numerical data parameters. |
| 17 | +4. **type**: Specifies whether the data parameter needs to be a number, an email address, or some other specific preset type. |
| 18 | +5. **pattern**: Specifies a [regular expression](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions) that defines a pattern the data parameter needs to follow. |
| 19 | +6. **business rules validation**: Specifies whether a request can be processed based on custom business rules. For example, a customer can use only 2 coupon codes in a day or a user cannot use the same email ID for more than one user account. |
| 20 | + |
| 21 | +### Implementing Validation |
| 22 | +You might be thinking do I have to write a bunch of if statements within my API routes for validation? Earlier this used to be the case, but now we have ready to use libraries that can be easily configured to setup validation on our APIs. |
| 23 | + |
| 24 | +We will be learning to use [express-validator](https://express-validator.github.io/docs/) in the next assignment. |
| 25 | + |
| 26 | +Consider this piece of code: |
| 27 | +``` |
| 28 | +// ...initial code omitted for simplicity |
| 29 | +const { body, validationResult } = require('express-validator'); |
| 30 | +
|
| 31 | +app.post( |
| 32 | + '/user', |
| 33 | + // username must be an email |
| 34 | + body('username').isEmail(), |
| 35 | + // password must be at least 5 chars long |
| 36 | + body('password').isLength({ min: 5 }), |
| 37 | + (req, res) => { |
| 38 | + // Finds the validation errors in this request and wraps them in an object with handy functions |
| 39 | + const errors = validationResult(req); |
| 40 | + if (!errors.isEmpty()) { |
| 41 | + return res.status(400).json({ errors: errors.array() }); |
| 42 | + } |
| 43 | +
|
| 44 | + // ...later code omitted for simplicity |
| 45 | + }, |
| 46 | +); |
| 47 | +``` |
| 48 | + |
| 49 | +Now, whenever a request that includes invalid username or password fields is submitted, your server will respond with a 400 error response like this: |
| 50 | +``` |
| 51 | +{ |
| 52 | + "errors": [ |
| 53 | + { |
| 54 | + "location": "body", |
| 55 | + "msg": "Invalid value", |
| 56 | + "param": "username" |
| 57 | + } |
| 58 | + ] |
| 59 | +} |
| 60 | +``` |
| 61 | + |
| 62 | +Basic validations can be handled by such middleware. However, custom validations based on specific business rules may require custom code. In any case, your server-side application must have a high level of validation across API routes and test cases ensuring that each and every erroneous possibility is checked and handled by sending a validation error response. A good validation response will help the frontend developers using your API to display graceful error messages to the end-user. |
| 63 | + |
| 64 | +--- |
| 65 | +## References |
| 66 | +- https://www.apisyouwonthate.com/blog/server-side-validation-with-api-descriptions |
| 67 | +- https://express-validator.github.io/docs/ |
0 commit comments