What is REST, both originally and popularly?

Representational state transfer, or REST, is a concept introduced and originally defined by one of the HTTP specifications’ principal authors, Dr. Roy T. Fielding on his doctoral dissertation.
It is a set of constraints under which Web-like architectures should operate, according to his thesis, so as to maximize the desirable qualities of a modern Web architecture.
The Web itself is the largest, most successful REST system in existence. Web browsers have built-in capabilities for handling HTML, CSS, JavaScript, images, and other standard web media types, but are not otherwise pre-programmed for browsing specific websites. All they need is a URL for knowing how to connect to a web server’s resource, typically an HTML web page.
The web page itself contains all the missing information for browsing that particular web site. This fulfills one of REST’s core constraints, known as HATEOAS, which stands for Hypermedia as the Engine of Application State.
Besides the standard media types and protocols built into web browsers for connecting to web server resources, all information for driving application state (i.e. browsing a website or running a web app) is delivered in-band with the content served by the web server, including code-on-demand (usually JavaScript) which extends client functionality, reducing the number of features that must be baked into the client.
In other words, a user’s possible actions and choices inside the application — say, a simple website — are made available by, and are dictated by the hypermedia the user is interacting with through the web browser. In this case, the hypermedia would be mostly HTML. Most specific user actions and choices are not made available by the browser itself; there’s no “Add Friend” or “Follow” button and no handling mechanism specifically for those kinds of buttons implemented on the browser itself, only on the web page hypermedia the browser is rendering.
However, REST is not limited to HTML, which is arguably the most common form of hypermedia, or HTTP. A system can be REST but use different types of hypertext and completely different communication protocols, so long as it properly implements HATEOAS and some other simpler constraints. That is what is at the very core of Dr. Fielding’s REST concept.
In short, REST systems are strongly Web-like, but not necessarily Web-based. In particular, being strongly HTTP-based doesn’t make things automatically RESTful. For example, most self-proclaimed RESTful APIs claim that title for being strongly HTTP-based, but fail to implement HATEOAS, and so can’t really be considered REST at all.
To Dr. Fielding’s dismay, what most people are talking about when they mention REST or RESTful APIs is something entirely different, and much harder to precisely define.
In an attempt to broadly define this “popular REST” concept, one could say it refers to making better use of HTTP’s features when building HTTP-based APIs. Contrary to the original REST definition, popular REST requires HTTP. It’s all about making the best use of it. But what does that mean, specifically?
HTTP offers a host of features relevant to HTTP-based API design, and popular REST enthusiasts all have their own set of favorites. This is what makes it hard to define; in practice, it means different things to different people.
In an upcoming article, Popular REST In-Depth, we’ll explore each of those features relevant to HTTP-based API design in much more detail.
