¿Usas REST o solo crees que lo haces?

Si eres desarrollador, la palabra REST te suena tanto como git commit -m "fix". La usas todos los días. Es el pan y la mantequilla de la comunicación entre tu frontend y tu backend, el motor silencioso detrás de cada like, cada scroll infinito y cada "Alexa, pon la canción de moda".

Creemos que la dominamos. GET para traer datos, POST para crear, PUT para actualizar y DELETE para borrar. Le ponemos un endpoint a cada acción del CRUD, devolvemos un JSON y ¡listo! A producción.

Pero, ¿y si te dijera que la mayoría de nosotros estamos usando REST como si tuviéramos un Porsche para ir a la tienda de la esquina? Estamos ignorando la ingeniería, la elegancia y el poder que se esconde bajo el capó.

Este no es otro post de documentación. Es una invitación a redescubrir la arquitectura que define la web moderna y a explorar sus rincones más oscuros y útiles.

Los Mandamientos Olvidados: Más Allá del Cliente-Servidor

Todos conocemos las reglas básicas: separación cliente-servidor, comunicación sin estado (stateless)... Pero es en la Interfaz Uniforme donde se esconde la verdadera magia, y es el mandamiento que más profanamos. Esta regla tiene cuatro pilares:

1. Identificación de Recursos (URIs)

Fácil. /users/123 es un usuario. /products/45 es un producto. Nombres, no verbos.

POST /createUser es un anti-patrón. El recurso es el usuario; el verbo HTTP (POST) es la acción.

2. Manipulación a través de Representaciones

Nunca obtienes el objeto de la base de datos directamente. Obtienes una representación (generalmente JSON).

Esto permite que el recurso interno evolucione sin que el cliente se rompa.

3. Mensajes Autodescriptivos

Cada mensaje debe contener la información para ser entendido.

Ejemplo: Content-Type: application/json le dice al cliente qué hacer con la respuesta. Simple, pero vital.

4. HATEOAS: Hypermedia as the Engine of Application State

Y aquí, amigos, está la joya de la corona.

La característica más poderosa y espectacularmente ignorada de REST.

HATEOAS: El GPS Integrado de tu API que Decidiste no Usar

Imagina que entras a un sitio web y, para navegar, tienes que escribir las URLs a mano porque no hay enlaces.

Absurdo, ¿verdad? Pues eso hacemos con nuestras APIs.

El cliente no debería saber que para obtener las órdenes de un usuario tiene que ir a /users/{id}/orders. ¡Esa es lógica del servidor!

HATEOAS significa que la respuesta de la API no solo te da los datos, sino también los enlaces a las siguientes acciones posibles.

Sin HATEOAS (como lo hacemos casi todos):

// GET /users/123

{

"id": 123,

"name": "Juan Developer",

"email": "[email protected]"

}

// El cliente tiene que construir la URL "/users/123/orders"

Con HATEOAS (el camino del Jedi):

// GET /users/123

{

"id": 123,

"name": "Juan Developer",

"email": "[email protected]",

"_links": {

"self": { "href": "/users/123" },

"orders": { "href": "/users/123/orders" },

"profile-picture": { "href": "/users/123/profile-picture" }

}

}

¿Por qué es revolucionario?

• Puedes cambiar la estructura de URLs en el backend sin romper clientes.
• El cliente sigue los enlaces, no construye rutas.
• Tu API se vuelve explorable y evolutiva.
• Desacoplas el cliente del servidor a un nivel superior.

¿Por qué casi nadie lo usa?

• Requiere más disciplina.
• Los frameworks no siempre lo facilitan.
• Vamos con prisa. Pero el costo inicial se paga con creces en mantenibilidad a largo plazo.

Los Verbos HTTP que Dejaste en el Visto

Todos usamos GET, POST, PUT y DELETE, pero hay más:

PATCH: El bisturí de cirujano

Mientras PUT reemplaza un recurso completo, PATCH aplica una actualización parcial.

¿Solo quieres cambiar el email del usuario? Usa PATCH.

HEAD: El espía

Es igual que GET, pero no devuelve el cuerpo, solo las cabeceras.

Útil para:

• Comprobar si un recurso ha cambiado (Last-Modified)
• Ver si existe
• Consultar tamaño (Content-Length)

OPTIONS: El explorador

Le pregunta al servidor:

"¿Qué métodos HTTP puedo usar en esta URL?"

El servidor puede responder:

Allow: GET, PUT, PATCH, DELETE

Es clave para CORS y clientes que auto-descubren capacidades.

Códigos de Estado: Tu API Puede Decir Más que "200 OK"

Usar bien los códigos de estado es como tener un vocabulario emocional rico:

• 201 Created: Se creó el recurso. Incluye Location: /users/124.
• 202 Accepted: Se aceptó la petición, pero el procesamiento será asincrónico.
• 204 No Content: Todo bien, pero no hay nada que devolver.
• 429 Too Many Requests: El cliente se pasó. Perfecto para rate limiting.

El Reto al Trono: ¿Sigue Siendo REST el Rey?

Sería negligente no mencionar a los retadores:

• GraphQL resuelve el over-fetching/under-fetching permitiendo pedir exactamente lo necesario.
• gRPC ofrece velocidad brutal en microservicios con HTTP/2 y Protobufs.

¿Está muerto REST?

No.

GraphQL y gRPC son herramientas especializadas.

Pero la simplicidad de REST, su universalidad y su base en HTTP lo mantienen como la lingua franca de las APIs.

No es una guerra de tecnologías. Es un abanico de soluciones.

La marca de un buen arquitecto no es elegir "la más nueva", sino la más adecuada.

Empieza a Usar el Porsche

La próxima vez que diseñes un endpoint, detente un segundo.

Piensa más allá del CRUD:

• ¿Podrías usar PATCH?
• ¿Tiene sentido devolver 201 Created con Location?
• ¿Y si agregas unos enlaces HATEOAS?

Dominar REST no es saberse los verbos. Es entender la filosofía.

Una web interconectada, desacoplada y resiliente.

Deja de usar tu Porsche para ir a la esquina.

Písale a fondo y descubre todo lo que puede hacer por ti.

¿Te gustó este post?

Compártelo con tu equipo. Rediseñen juntos esa API legacy.