Representational State Transfer is Roy Fielding’s name for the architectural style that makes the web work. Resources are identified by URLs. You manipulate them through the standard HTTP methods — GET, POST, PUT, PATCH, DELETE. Responses carry representations of resource state, and status codes communicate the outcome. That is the whole idea, and it is a good one.
REST won the API world because it was simpler, more accessible, and more aligned with how the web already worked than the heavyweight alternatives that came before it. You did not need an enterprise architecture team to make your first call. You needed a URL and curl.
What “REST” means in practice, though, is looser than what it means in the dissertation. The vast majority of APIs that call themselves RESTful do not satisfy Fielding’s constraints — most notably the hypermedia constraint. They are resource-oriented HTTP APIs with sensible conventions, and everyone understands what you mean when you call them REST. I have made my peace with that. I am not a card-carrying RESTafarian; I just believe in the web.
My advice is to take REST’s useful conventions seriously and its purity debates not at all. Shaming people for not being RESTful enough is a large part of why API design is as inconsistent as it is — you alienate people from the shared conventions and they go invent their own. Consistency is the actual goal. REST, used pragmatically, is how most organizations get there.
