El método
- ¿Qué recursos existen en el problema?
- ¿Qué operaciones se hacen con cada uno, y qué responden?
- ¿Qué se valida, y dónde?
- ¿Qué capa se ocupa de cada cosa?
- ¿Qué pasa cuando falla, y qué ve quien llamó?
- ¿Cómo demuestro que funciona sin probarlo a mano?
La idea más importante
Diseña el contrato antes que la implementación, y sostenlo. Todo lo que llega de fuera es sospechoso; todo lo que sale es una decisión.
De ahí sale todo lo demás: por eso las rutas hablan de recursos, por eso los errores tienen una forma única, por eso la validación vive en el servidor con lista blanca, por eso las respuestas se construyen en lugar de volcarse, y por eso las capas están separadas.
Las tres capas del módulo, juntas
- HTML · qué existe y qué significa
- CSS · cómo se presenta y se adapta
- JavaScript · qué ocurre en el navegador
- Node · qué ocurre en el servidor
- API · el contrato que une las dos mitades
Una idea ha aparecido en las seis unidades bajo formulaciones distintas: separa lo que cambia por razones distintas. Estructura de presentación, lógica de interfaz, reglas de almacén, contrato de implementación. Cada vez que lo hiciste, la unidad siguiente te costó menos.
Al terminar deberías poder responder
- ¿Qué distingue una API orientada a recursos de una orientada a acciones?
- ¿Dónde van los filtros y por qué no en la ruta?
- ¿Qué significa que una API no guarde estado?
- ¿Qué piezas forman el contrato de una API?
- ¿Qué código devuelve cada operación del CRUD, en éxito y en error?
- ¿Cuándo un 400 y cuándo un 404?
- ¿Por qué una búsqueda sin resultados no es un 404?
- ¿Qué diferencia hay entre PUT y PATCH?
- ¿Qué operaciones se pueden repetir sin efectos distintos?
- ¿Qué es una lista blanca de campos y qué evita?
- ¿Por qué el identificador lo asigna el servidor?
- ¿Qué sabe y qué no sabe cada capa?
- ¿Cómo compruebas que las capas están bien separadas?
- ¿Por qué la aplicación se crea sin arrancarse?
- ¿Por qué se normalizan los datos al leerlos del almacén?
- ¿Cómo se traduce un error interno a un código HTTP?
- ¿Para qué sirve el identificador de petición?
- ¿Por qué el cliente puede tratar todos los errores con una función?
- ¿Qué ventajas tiene generar el HTML en el servidor?
- ¿Qué es el cross-site scripting y cómo se evita?
- ¿Cuándo filtrar en el cliente y cuándo en el servidor?
- ¿Por qué se deshabilita el botón durante un envío?
- ¿Por qué la aplicación debe negarse a arrancar si falta una variable?
- ¿Qué protege CORS y qué no protege?
- ¿Qué diferencia hay entre 401 y 403?
- ¿Qué protecciones mínimas necesita un servicio expuesto?
- ¿Qué se prueba de una API, y cómo compruebas que la prueba sirve?
- ¿Qué pasa con un fichero de datos en un servicio desplegado?
- ¿Qué apartados no pueden faltar en un README?
- Si hubiera que cambiar el almacén, ¿qué ficheros tocarías?
El vocabulario de la unidad
| Concepto | Significa |
|---|---|
| Recurso | Una cosa del problema identificable con una URL |
| REST | Un estilo de API basado en recursos, métodos y estados |
| Contrato | Lo que la API promete: rutas, cuerpos, códigos y formas |
| Sin estado | Que el servidor no recuerda nada entre peticiones |
| CRUD | Crear, leer, actualizar y borrar |
| Repetible sin efectos | Que repetir la operación no cambie el resultado |
| Router | Un grupo de rutas montado bajo una ruta base |
| Capa | Una parte del sistema con una responsabilidad y sus límites |
| Servicio | La capa donde viven las reglas de negocio |
| Repositorio | La capa que sabe cómo se guardan y leen los datos |
| Lista blanca | Aceptar solo lo enumerado y descartar el resto |
| Normalizar | Dar forma conocida a un dato al leerlo |
| Escapar | Sustituir caracteres con significado en HTML por entidades |
| Cross-site scripting | Ejecutar código ajeno en el navegador de un visitante |
| CORS | La política del navegador sobre peticiones a otro origen |
| Limitación de peticiones | Rechazar llamadas por encima de una frecuencia |
| Identificador de petición | Un código que relaciona una respuesta con su traza |
| Siembra | Poblar el almacén con datos conocidos |
| Despliegue | Publicar la aplicación en un servidor accesible |
Y ahora
Has terminado el módulo. Empezaste escribiendo un encabezado y terminas con una aplicación publicada en internet, con su cliente, su API, sus pruebas y su documentación.
Lo que viene después ya no es lenguaje de marcas: es un backend con base de datos, seguridad, transacciones y despliegue serio, y un cliente construido con framework. Las preguntas, sin embargo, serán las mismas que vienes formulándote durante seis unidades.
- ¿Qué significa esto, más allá de cómo se ve?
- ¿De qué tipo es este dato, de verdad?
- ¿Dónde vive la verdad de esta información?
- ¿Quién valida esto, y qué pasa si mienten?
- ¿Qué se ve cuando falla?
- ¿Puede usarlo alguien que no ve la pantalla?
- ¿Sabría explicar por qué lo hice así?
Esas preguntas no caducan con la tecnología. El framework de dentro de cinco años será otro; las preguntas, no.
Ya deberías ser capaz de
- Diseñar una API REST a partir de sus recursos, no de las pantallas que la usan.
- Elegir método, ruta y código de estado para cada operación, y sostener ese contrato.
- Implementar el CRUD completo con validación de entrada en todas las operaciones.
- Separar rutas, servicio y repositorio, de forma que cambiar el almacén no toque las rutas.
- Definir un contrato de errores estable y usarlo desde el cliente.
- Generar HTML en el servidor escapando el contenido que viene de fuera.
- Conectar el cliente de la UD4 con la API propia, incluidos los formularios.
- Configurar la aplicación por entorno y aplicar la seguridad mínima exigible.
- Escribir pruebas automáticas de la API con el ejecutor incluido en Node.
- Documentar y desplegar el servicio, y defender técnicamente las decisiones tomadas.