REST (Representational State Transfer) es un estilo arquitectónico para aplicaciones en red, definido por Roy Fielding. No es un protocolo ni un estándar — es un conjunto de restricciones (constraints) que, cuando se siguen, hacen que una API sea escalable, cacheable y fácil de evolucionar. Una API "RESTful" modela todo como recursos (users, orders, products) identificados por URIs, y los manipula usando HTTP methods estándar.
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 42, "name": "Ann", "email": "[email protected]" }
El URI /users/42 nombra el recurso; GET es la acción; JSON es la representación. Esa combinación — sustantivos en el path, verbos como HTTP methods — es el corazón de REST.
REST es el estilo dominante para las web APIs, así que los entrevistadores usan esta pregunta para comprobar que entiendes por qué funciona, no solo que sabes deletrearlo. Las dos restricciones que más importan en la práctica son el statelessness (cada request es autocontenido, así que puedes poner cualquier número de servers detrás de un load balancer y escalar horizontalmente sin sticky sessions) y la uniform interface (URLs predecibles y orientadas a recursos más HTTP methods y status codes estándar, lo que significa que los clients no necesitan lógica a medida por endpoint). Una buena respuesta conecta las restricciones con beneficios concretos — el statelessness habilita el escalado, la cacheabilidad reduce la carga, el layered system te permite insertar CDNs y gateways — y señala que la mayoría de las APIs "REST" son pragmáticas más que plenamente RESTful (pocas implementan HATEOAS). Entender estas restricciones es la base de cualquier otra decisión de diseño REST, desde elegir status codes hasta el versioning.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar