!!! Overview
[{$pagename}] or [REST] is an [Software Architecture Model] that sets certain [constraints] for designing and building large-scale distributed [hypermedia] systems. [{$pagename}] is often, improperly, used only as a [API] transport over [HTTP]As an [architectural|Architecture] style, [{$pagename}] has very broad application. The designs of both HTTP 1.1 and also URIs follow [RESTful] principles. 

The [World Wide Web] is no doubt the largest and best known [REST] application. Many other web services also follow the [REST] architectural style. Examples include [OAuth 2.0] and [OpenID Connect] 1.0.

[{$pagename}] objects are defined as addressable [URIs], and are typically interacted with using the built-in verbs or [HTTP Method] — specifically, [GET|HTTP GET], [PUT|HTTP PUT], [DELETE|HTTP DELETE], [POST|HTTP POST], etc. [{$pagename}] was defined by Roy Fielding in his [2000|Year 2000] PhD dissertation "''Architectural Styles and the Design of Network-based Software Architectures''" [2]
!! [{$pagename}] [Data] Elements
%%zebra-table
%%sortable
%%table-filter
||Data Element||Modern [Web] [Examples]
|[resource]|the intended conceptual target of a hypertext reference
|[resource] [identifier]|[URL], [URN]
|representation|[HTML] document, JPEG image
|representation [metadata]|media type, last-modified time
|[resource] [metadata]|source link, alternates, vary
|control data|if-modified-since, [Cache-Control]
/%
/%
/%

!! [{$pagename}] is [stateless]
All [REST] interactions are [stateless]. That is, each [request] contains all of the information necessary for a connector to understand the request, independent of any [requests] that may have preceded it. This restriction accomplishes four functions: 
* it removes any need for the connectors to retain application [state] between requests, thus reducing consumption of physical [resources] and improving scalability; 
* it allows interactions to be processed in parallel without requiring that the processing mechanism understand the interaction semantics; 
* it allows an [intermediary] to view and understand a request in isolation, which may be necessary when services are dynamically rearranged; and, 
* it forces all of the information that might factor into the reusability of a cached response to be present in each [request].

!! [REST] [APIs] [MUST] be hypertext-driven [3]
[API] designers, please note the following rules before calling your creation a [REST] API:
* A [REST] [API] should __NOT__ be dependent on any single communication [protocol], though its successful mapping to a given [protocol] may be dependent on the availability of [metadata], choice of methods, etc. In general, any protocol element that uses a [URI] for identification must allow any URI scheme to be used for the sake of that identification. __Failure__ here implies that identification is not separated from interaction.
* A [REST] [API] should __NOT__ contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, such as [HTTP PATCH] method or Link header field. Workarounds for broken implementations (such as those [browsers] stupid enough to believe that [HTML] defines [HTTP]’s method set) should be defined separately, or at least in appendices, with an expectation that the workaround will eventually be obsolete. __Failure__ here implies that the resource interfaces are object-specific, not generic.
* A REST API [SHOULD] spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. 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 (and, in most cases, already defined by existing media types). __Failure__ here implies that out-of-band information is driving interaction instead of hypertext.]
* A REST API [MUST NOT] define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and [URI] templates, by defining those instructions within media types and link relations. __Failure__ here implies that clients are assuming a [resource] structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to [RPC]’s functional coupling.
* A [REST] [API] [MUST NOT]  have "typed" [resources] that are significant to the client. Specification authors may use resource types for describing server implementation behind the interface, but those types [MUST] be irrelevant and invisible to the [client]. The only types that are significant to a client are the current representations media type and standardized relation names. 
* A [REST] [API] should be entered with no prior knowledge beyond the initial [URI] (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the [API]). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand). (__Failure__ here implies that out-of-band information is driving interaction instead of hypertext.)!! [{$pagename}] Limitations[1]
In [{$pagename}], [Hypermedia As The Engine Of Application State] ([HATEOAS]) is an [architecture] [constraint] in which the [client] interacts with [hypermedia] links, rather than through a specific interface.
With [REST], the core concept is that everything is a [resource]. While [REST] was a great solution when it was first proposed, there are some pretty significant issues that the architecture suffers from. 

[REST]’s defining feature is the ability to reference [resources] — the problem is when those [resources] are complicated and relational in a more complex organization known as a [graph]. Fetching these complicated [graphs] may require multiple [round-trips] between the client and server.

What this ultimately results in is a system where the more useful it is, the slower it is. In other words, as more relational data is presented, the [REST] system chokes on itself.

!! [GraphQL]

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [http://nordicapis.com/is-graphql-the-end-of-rest-style-apis/|Wikipedia:http://nordicapis.com/is-graphql-the-end-of-rest-style-apis/|target='_blank'] - based on information obtained 2017-03-12- 
* [#2] - [Representational State Transfer (REST)|http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm|target='_blank'] - based on information obtained 2017-03-12- 
* [#3] - [REST APIs must be hypertext-driven|http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven|target='_blank']