Validaciones API: práctica

Esta publicación es una continuación de la primera publicación de validaciones en Laravel que escribimos sobre el tema de Validaciones API en laravel, es importante que vayas a verlo antes de continuar aquí, o al menos revisa el video el video que preparamos para ti, de esa primera parte

En la primera parte de esta publicación habíamos trabajado en validar los datos necesarios para la inserción de la tabla “checkins”, pero no nos detuvimos lo suficiente en explicar cada una de las reglas de validación que se usaban, porque de hacerlo, la publicación hubiese sido muy extensa, es por ello que ahora, en esta segunda parte explicaremos a detalle qué reglas de validación usamos con una tabla con más campos: “huéspedes”.

Validar datos de entrada en la tabla “Huéspedes” paso a paso:

Paso 1: Ejecuta los siguientes comandos, para crear un modelo y un controlador

Paso 2: Crea la ruta:

Paso 3: Edita el modelo:

Paso 4: Crea el controlador:

Observa con atención el recuadro rojo de la imagen anterior; lo que hay en su interior son las reglas de validación que estoy usando en el controlador:

'codigo_checkin'  => 'required | integer | exists:checkins,id'
En esta línea se están usando tres reglas de validación: “required” que nos indica que el campo que esté bajo esta regla debe estar presente y no estar vacío; “integer” esta regla indica que el valor del campo debe ser un número; y por último: “exists” esta regla requiere dos parámetros, el primero debe ser el nombre de una tabla, y el segundo una columna de esa misma tabla. En resumen las tres reglas de validación te estan diciendo que el campo “codigo_checkin” si o si debe formar parte de tu consulta post y que además debe ser un número, que se corresponda con un “id” guardado en la tabla “checkins”.

'nombre'  => 'required | string'
Esta es bastante sencilla, se especifican dos reglas: “required” que nos indica que el campo debe estar presente en la consulta post y no estar vacío; y “string” que como supondrás, significa que el campo “nombre” solo debe tener cadenas de texto, puedes ponerle números pero estos deben ser parte de la cadena, es decir deben estar dentro de comillas.

'correo_electronico' => 'required | email'
Aquí nuevamente se especifican dos reglas: “required” que nos indica que el campo debe estar presente en la consulta post y no estar vacío; y “email” (mi favorito) que detecta si lo escrito para el campo tiene formato de correo electrónico, es decir “algo@algo.com”

'sexo' => [ 'required' , 'string', Rule::in(['m', 'f'] ) ],
Esta regla tiene los campos de “required” y “string”, es decir el campo debe ser obligatorio colocarlo y además debe ser una cadena, pero la tercera regla “Rule” es especial, porque le indica al campo “sexo” que solo se pueden colocar un caracter de tipo cadena que sera o una “m” o una “f” en referencia a masculino y femenino.

'tipo' => 'required | integer | exists:documentos,id'
Estas tres reglas de validación juntas le indican al campo “tipo” que si o si debe formar parte de tu consulta post, es decir es requerido o obligatorio y que además debe ser un número, que se corresponda con un “id” guardado en la tabla “documentos”.

'numero_documento' => 'required | integer'
Esta también es bastante sencilla, ambas reglas indican que el campo “numero_documento” es obligatorio que forma parte de la consulta post, que no esté vacío y que además debe ser un número.

'fecha_expedicion' => 'required | date'
Las reglas “required” y “date” juntas le indican al campo “fecha_expedicion” que además de ser obligatorio colocarlo, lo que escribas en él debe ser una cadena en un formato de fecha válido para PHP.

'titular' => [ 'required' , 'string' , Rule::in(['0', '1']) ]
Para este ultimo ejemplo, se repiden las reglas del campo “sexo” pero lo especial en este caso es que la regla “Rule” se esta aplicando sobre dos numeros, a pesar de que la regla anterior es “string”; puede pareser que hay conflito entre ambas, pero no hay problema en ambas reglas, porque los numero “0” y “1” simplemente se trataran como cadenas, no como enteros.

Si probamos lo anterior editado, en nuestro postman, veremos:

Leido 1752 veces