A person looking to understand &quot;What is REST? What is a RESTful application?&quot; would be well-served by considering <i>websites</i> rather than web services.<p>Facebook, Amazon, and Hacker News are good examples of RESTful applications. You can enter them through their website roots with no prior knowledge beyond standard web media types like HTML&#x2F;CSS. The site roots display some information, expose some functionality like search, and link to pages with more capabilities like to create an account. The search function is expressed as an HTML form, and when the user submits their search, the HTML spec tells the browser to navigate to a new URL composed from the search form fields. The search result page displays a list of hyperlinks to other resources, such as products on Amazon or people on Facebook. Navigating to those pages lets you discover information and hyperlinks to other resources such as a person&#x27;s photos, related products, etc.<p>The way a browser navigates through a website by following links is the classic example of a RESTful application, and is the meaning of &quot;hypermedia as the engine of application state&quot;. Fielding also wrote a blog post clarifying REST and its constraints: <a href="http:&#x2F;&#x2F;roy.gbiv.com&#x2F;untangled&#x2F;2008&#x2F;rest-apis-must-be-hypertext-driven" rel="nofollow">http:&#x2F;&#x2F;roy.gbiv.com&#x2F;untangled&#x2F;2008&#x2F;rest-apis-must-be-hyperte...</a><p>&gt; A REST API should be entered with no prior knowledge beyond the initial URI and set of standardized media types that are appropriate for the intended audience. A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). A REST API should never have “typed” resources that are significant to the client. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type<p>Some confusion about REST seems to stem from misguided attempts to apply REST to scenarios for which it&#x27;s not a good fit - scenarios where there is by necessity tight coupling in the form of mutual knowledge of specific data types and operations. Other confusion about the term &quot;REST&quot; comes from applying subset of its principles, resulting in a popular label that refers to a large spectrum of architectural styles. The Richardson Maturity Model helps organize these functionality subsets into levels that can be named and considered separately - services termed REST are sometimes level 1 or 2 in the Richardson model.<p><a href="http:&#x2F;&#x2F;martinfowler.com&#x2F;articles&#x2F;richardsonMaturityModel.html" rel="nofollow">http:&#x2F;&#x2F;martinfowler.com&#x2F;articles&#x2F;richardsonMaturityModel.htm...</a>