TEMA 6

Introducción al Back-End
ÍNDICE

1.¿Qué es el Back-End?
2.Tecnologías principales
3.API REST
1/
¿Qué es el Back-End?
¿Qué es el Back-End?

¿Qué es el Back-End?

• La otra cara, junto con el Front-End, de una aplicación web.

• Se encarga principalmente de procesar, obtener, almacenar y asegurar recursos o

datos necesarios para que el negocio prevalezca.

4
¿Qué es el Back-End?

¿Qué componentes forman parte del Back-End?

5
¿Qué es el Back-End?

¿Qué componentes forman parte del Back-End?

• Servidores HTTP, DNS, SMTP, FTP

• Gestores de colas (mensajería asíncrona)
• Servicios Web
• APIs REST
• Bases de datos
• Balanceadores de carga
• Proxies
• Firewalls
• Frameworks y lenguajes de programación orientados a Back-End
• …

6
¿Qué es el Back-End?

¿Un componente dentro del Back-End puede ser accedido de cualquier

forma? ¿De qué forma se debería permitir su acceso y/o modificación?

7
¿Qué es el Back-End?

¿Un componente dentro del Back-End puede ser accedido de cualquier

forma? ¿De qué forma se debería permitir su acceso y/o modificación?

• Un componente del Back-End NUNCA debe ser accesible a un usuario cualquiera (o

disponible a través de Internet). Regularemos su acceso y uso mediante APIs REST
o Servicios Web (old style).

8
2/
Tecnologías principales
Lenguajes y Frameworks

10
Lenguajes y Frameworks

11
Bases de datos

12
Exposición

13
2/
API REST
API REST

API REST

• REST es un estilo de arquitectura de software para diseñar APIs. Definido por uno
de los padres de la especificación del protocolo HTTP (Roy Fielding).

• Ampliamente utilizado a día de hoy como la opción por defecto para interconectar
sistemas a través del protocolo HTTP.

15
API REST

En REST no hay estado

• Cualquier API REST es stateless. Los servicios que implementen la API perderán
toda la información entre dos llamadas cualesquiera.

• Si se requiere estado, es una responsabilidad del cliente (mediante tokens por

ejemplo…)

• Es una ventaja de cara al servidor, ya que escala más fácilmente y no requiere

espacio para almacenar una sesión.
• Es una ”desventaja” para el cliente ya que si se requiere información de sesión
tiene que gestionarla él.

16
API REST

Orientación a RECURSOS

• ¡Recursos everywhere!

• Tenemos que identificar los recursos que usa nuestra API.

• Un recurso es un sustantivo, no un verbo (como en ws).
• Se definen en plural.
• Accesibles mediante URIs (Uniform Resource Identifier).

17
API REST

Uso concienzudo de los métodos HTTP

• ¿Cuáles son los métodos HTTP más habituales?

18
API REST

Uso concienzudo de los métodos HTTP

• ¿Cuáles son los métodos HTTP más habituales?

• GET: Consulta de datos de recursos.

• POST: Creación de recursos.
• PUT: Modificación sobre recursos.
• PATCH: Modificación parcial sobre recursos.
• DELETE: Eliminación de recursos.
• HEAD: Headers de una respuesta a una petición GET.

¿Seguridad? ¿Idempotencia?

19
API REST

Método HTTP GET

• Seguridad: No realiza modificaciones en el estado de ningún recurso.

• Idempotencia: Múltiples llamadas no modifican el estado de los recursos. 20
API REST

Método HTTP GET

Seguro
Idempotente

• Seguridad: No realiza modificaciones en el estado de ningún recurso.

• Idempotencia: Múltiples llamadas no modifican el estado de los recursos. 21
API REST

Método HTTP POST

• Seguridad: No realiza modificaciones en el estado de ningún recurso.

• Idempotencia: Múltiples llamadas no modifican el estado de los recursos. 22
API REST

Método HTTP GET

No Seguro
No Idempotente

• Seguridad: No realiza modificaciones en el estado de ningún recurso.

• Idempotencia: Múltiples llamadas no modifican el estado de los recursos. 23
API REST

Método HTTP PUT

• Seguridad: No realiza modificaciones en el estado de ningún recurso.

• Idempotencia: Múltiples llamadas no modifican el estado de los recursos. 24
API REST

Método HTTP PUT

No Seguro
Idempotente

• Seguridad: No realiza modificaciones en el estado de ningún recurso.

• Idempotencia: Múltiples llamadas no modifican el estado de los recursos. 25
API REST

Método HTTP PATCH

• Seguridad: No realiza modificaciones en el estado de ningún recurso.

• Idempotencia: Múltiples llamadas no modifican el estado de los recursos. 26
API REST

Método HTTP PATCH

No Seguro
No Idempotente

• Seguridad: No realiza modificaciones en el estado de ningún recurso.

• Idempotencia: Múltiples llamadas no modifican el estado de los recursos. 27
API REST

Método HTTP DELETE

• Seguridad: No realiza modificaciones en el estado de ningún recurso.

• Idempotencia: Múltiples llamadas no modifican el estado de los recursos. 28
API REST

Método HTTP DELETE

No Seguro
Idempotente

• Seguridad: No realiza modificaciones en el estado de ningún recurso.

• Idempotencia: Múltiples llamadas no modifican el estado de los recursos. 29
API REST

Uso concienzudo de los métodos HTTP

• ¿Cuáles son los métodos HTTP más habituales?

• GET: Consulta de datos de recursos. Seguro e Idempotente.

• POST: Creación de recursos. No seguro y No Idempotente.
• PUT: Modificación sobre recursos. No seguro e Idempotente.
• PATCH: Modificación parcial sobre recursos. No seguro y No Idempotente.
• DELETE: Eliminación de recursos. No seguro e Idempotente.
• HEAD: Headers de una respuesta a una petición GET. Seguro e Idempotente.

30
Consideraciones sobre REST

REST es un estilo arquitectónico

• Una organización puede elegir no adoptar el estilo al 100% y tener PUT que realicen
modificaciones parciales, modificar recursos con POST, GET con body…

• Cuándo una API REST cumple todas las características anteriores se denomina
RESTFUL.

• Las entradas y salidas de las llamadas que se realicen a la API suelen codificarse
mediante JSON.

• Los códigos de error están para algo….

31
Consideraciones sobre REST

Los códigos de error SIRVEN. ÚSALOS

• 100 - 199

• 200 – 299

• 300 – 399

• 400 – 499

• 500 - 599

• Más información sobre cada código.

32
Consideraciones sobre REST

Los códigos de error SIRVEN

• 100 – 199: Informativas.

• 200 – 299: Respuesta OK.

• 300 – 399: Redirección.

• 400 – 499: Errores por parte del cliente.

• 500 – 599: Errores por parte del servidor.

• Más información sobre cada código.

33
API REST - CONSUMO

Hay dos formas de consumir una API

• De forma programática. Lo haremos en los próximos temas.

• De forma manual. Con programas como Postman.

34
API REST - CONSUMO

Recurso Audiovisual Importante

06.01
Consumir una API REST con Postman

35
2/
API REST - EJEMPLO
API REST - EJEMPLO

Ejemplo de diseño de una API

La empresa de delivery de Madrid FastRestFood está desarrollando una aplicación web

y aplicaciones móviles para iOS y Android para que los usuarios puedan u>lizar sus
servicios. Para dar soporte a los diferentes canales, se ha contratado a una empresa
externa que se encargará del desarrollo completo del Back-End. Dado que otra
empresa será la encargada del desarrollo de los frontales, se ha acordado compar>r
una primera versión de una API REST para que el equipo encargado de los frontales
pueda progresar en sus desarrollos. La API REST debe soportar las siguientes
operaciones desde el punto de vista de negocio:

- Creación (1) y consulta de pedidos (todos los disponibles (2) y uno concreto (3))
- Añadir (6) o eliminar (7) platos a un pedido.
- Añadir (8) comentarios en un restaurante
37
API REST - EJEMPLO

Ejemplo de diseño de una API

38
API REST - EJEMPLO

Ejemplo de diseño de una API

39
API REST - EJEMPLO

No hay una única solución

• Los diseños de APIs REST, como cualquier diseño, son todos únicos.

• La mayoría de códigos de respuesta HTTP son compartidos.

• En función de la operación algunos códigos de respuesta cambian, como las

confirmaciones. 200 en lectura y 201 en creación de recursos.

40
¿DUDAS?
HANDS ON!
DISEÑO DE API REST

GIT API REST Entrega

Actualiza tu Fork. Las Diseñaremos varias APIs Tablas TXT.
instrucciones de este REST para casos de uso
ejercicio se encuentran reales.
en la carpeta Tema_6.

43
Gracias