REST para Oposiciones TAI: Guía Completa

¿Qué es REST?

REST (Representational State Transfer) es un estilo de arquitectura para el diseño de servicios web que permite la comunicación entre clientes y servidores utilizando el protocolo HTTP.

Fue propuesto por Roy Fielding en el año 2000 y define un conjunto de restricciones que permiten construir APIs simples, escalables e independientes de la plataforma.

REST no es un protocolo ni un estándar, sino un estilo arquitectónico.

Conceptos fundamentales

Para comprender REST es imprescindible conocer los siguientes conceptos:

• Recurso (Resource): cualquier elemento accesible mediante una URI.
• URI (Uniform Resource Identifier): identifica de forma única un recurso.
• Representación: formato en el que se intercambia un recurso (JSON, XML...).
• Cliente: aplicación que realiza peticiones.
• Servidor: aplicación que expone los recursos.
• Métodos HTTP: operaciones sobre los recursos.

Funcionamiento de REST

El cliente realiza una petición HTTP indicando:

• La URI del recurso.
• El método HTTP.
• Opcionalmente, datos en el cuerpo de la petición.

El servidor:

1. Recibe la petición.
2. Procesa la operación solicitada.
3. Devuelve una respuesta HTTP.
4. Incluye un código de estado y, normalmente, una representación del recurso.

Cliente

   │

HTTP Request

(GET, POST, PUT...)

   │

Servidor REST

   │

HTTP Response

(200 OK + JSON)

Características de REST

REST presenta las siguientes características:

• Arquitectura cliente-servidor.
• Comunicación sin estado (Stateless).
• Uso de HTTP.
• Recursos identificados mediante URI.
• Interfaz uniforme.
• Posibilidad de utilizar caché.
• Arquitectura escalable.

Restricciones de REST

Para que una API sea considerada RESTful debe cumplir una serie de restricciones.

Cliente-Servidor

Cliente y servidor son independientes.

Esto permite evolucionar ambos sistemas sin afectar al otro.

Stateless

Cada petición contiene toda la información necesaria para ser procesada.

El servidor no almacena información sobre peticiones anteriores.

Cacheable

Las respuestas pueden almacenarse en caché cuando sea posible.

Esto reduce el número de peticiones al servidor y mejora el rendimiento.

Interfaz uniforme

Todos los recursos siguen las mismas reglas de acceso.

Por ejemplo:

GET /usuarios
GET /usuarios/15
POST /usuarios
PUT /usuarios/15
DELETE /usuarios/15

Sistema en capas

El cliente desconoce si está comunicándose directamente con el servidor o con un proxy, balanceador o gateway intermedio.

Recursos y URI

Cada recurso posee una dirección única denominada URI.

Ejemplos:

/usuarios
/usuarios/25
/productos
/pedidos/108

Una buena práctica consiste en utilizar:

• Sustantivos.
• Minúsculas.
• Plurales.
• Sin verbos.

✅ Correcto:

GET /clientes

❌ Incorrecto:

GET /obtenerClientes

Métodos HTTP

Los métodos HTTP representan las operaciones CRUD sobre los recursos.

Ejemplos:

GET /productos

Obtiene todos los productos.

POST /productos

Crea un nuevo producto.

DELETE /productos/15

Elimina el producto 15.

Códigos de estado HTTP

El servidor devuelve un código indicando el resultado de la operación.

Formatos de intercambio

REST puede utilizar distintos formatos para representar los recursos.

Los más habituales son:

• JSON.
• XML.

Actualmente, JSON es el formato predominante por su simplicidad y menor tamaño.

Ejemplo:

{
  "id": 15,
  "nombre": "Ana",
  "edad": 28
}

Idempotencia

Una operación es idempotente cuando ejecutarla varias veces produce el mismo resultado.

Comparación REST vs SOAP

Caso práctico

Situación

Una aplicación móvil necesita consultar y actualizar la información de los usuarios mediante Internet.

Solución

Se desarrolla una API REST.

GET /usuarios/8

Obtiene los datos del usuario.

PUT /usuarios/8

Actualiza toda la información del usuario.

DELETE /usuarios/8

Elimina el usuario.

Gracias a la arquitectura REST, cualquier cliente compatible con HTTP puede consumir la API.

Ventajas e inconvenientes

Ventajas

• Sencillez.
• Escalabilidad.
• Independencia entre cliente y servidor.
• Gran compatibilidad.
• Uso de estándares HTTP.
• Fácil integración con aplicaciones web y móviles.

Inconvenientes

• HTTP puede introducir cierta sobrecarga.
• No define un contrato estricto como SOAP.
• El cumplimiento de REST depende del diseño de la API.
• Las operaciones complejas pueden requerir múltiples peticiones.

Errores habituales

• Pensar que REST es un protocolo.
• Confundir REST con HTTP.
• Utilizar verbos en las URI.
• No respetar los métodos HTTP.
• Creer que Stateless significa que no existe autenticación.
• Devolver códigos HTTP incorrectos.
• Utilizar POST para operaciones que deberían realizarse mediante PUT o DELETE.

Cómo evitarlos

• Recordar que REST es un estilo arquitectónico.
• Diseñar las URI utilizando recursos.
• Utilizar correctamente los métodos HTTP.
• Memorizar los principales códigos de estado.
• Entender el significado de Stateless.

Relaciones con otros temas

REST está estrechamente relacionado con:

• HTTP.
• JSON.
• XML.
• APIs.
• Servicios web.
• Arquitectura cliente-servidor.
• TCP/IP.
• Microservicios.
• Desarrollo web.

Conceptos clave para recordar

[!NOTE]

• REST es un estilo arquitectónico, no un protocolo.
• Fue definido por Roy Fielding en el año 2000.
• Se basa en el protocolo HTTP.
• Todo gira alrededor de los recursos, identificados mediante URI.
• Las operaciones se realizan mediante los métodos GET, POST, PUT, PATCH y DELETE.
• Una API REST debe ser Stateless, es decir, cada petición contiene toda la información necesaria.
• Los formatos más utilizados son JSON y, en menor medida, XML.
• Los códigos de estado HTTP indican el resultado de la operación (200, 201, 404, 500, etc.).
• REST es la arquitectura predominante para el desarrollo de APIs web y microservicios.