REST (Representational State Transfer) é um estilo arquitetural para aplicações em rede, definido por Roy Fielding. Não é um protocolo nem um padrão — é um conjunto de constraints que, quando seguidas, tornam uma API escalável, cacheável, e fácil de evoluir. Uma API "RESTful" modela tudo como recursos (users, orders, products) identificados por URIs, e os manipula usando métodos HTTP padrão.
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]" }
A URI /users/42 nomeia o recurso; GET é a ação; JSON é a representation. Essa combinação — substantivos no path, verbos como métodos HTTP — é o coração do REST.
REST é o estilo dominante para web APIs, então os entrevistadores usam esta pergunta para checar se você entende por que ele funciona, não apenas se sabe soletrá-lo. As duas constraints que mais importam na prática são a statelessness (cada request é autocontido, então você pode colocar qualquer quantidade de servers atrás de um load balancer e escalar horizontalmente sem sticky sessions) e a uniform interface (URLs previsíveis e orientadas a recursos mais métodos HTTP e status codes padrão, o que significa que os clients não precisam de lógica customizada por endpoint). Uma resposta forte conecta as constraints a benefícios concretos — a statelessness viabiliza o escalonamento, a cacheabilidade reduz a carga, o layered system permite inserir CDNs e gateways — e nota que a maioria das APIs "REST" é pragmática em vez de plenamente RESTful (poucas implementam HATEOAS). Entender essas constraints é a base para toda outra decisão de design REST, de escolher status codes a versionamento.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar