The document provides an introduction to HATEOAS (Hypermedia as the Engine of Application State), which is one of the constraints of REST.
It defines HATEOAS as using hypermedia links in responses to drive application state, rather than through out-of-band information. Popular web APIs often violate HATEOAS by not including these links, unlike web user interfaces which adhere to it.
While including links in API responses may be helpful for developers, it does not truly implement HATEOAS unless the links drive the client application state at runtime, rather than the developer deciding application flow. A true HATEOAS client would handle generic RESTful APIs similar to how a feed reader handles synd
10. The Constraints of REST
1. Client-server
2. Stateless server
3. Cache
4. Uniform interface
a. Identification of resources
b. Manipulation of resources through representations
c. Self-descriptive messages
d. Hypermedia as the engine of application state
5. Layered System
6. Code-On-Demand (optional)
14. âŠgive us the client-cache-stateless-server web architecture.
15. client
cache
Each request
must contain
all information. No stored
context on the stateless
server. server
Client has the
right to reuse
client response data.
cache
17. The 5th constraint, Layered System, lets us add
features like a gateway, load balancer and firewall.
18. Each layer Layers can encapsulate
provides services legacy services & protect
new services from legacy stateless
to itâs neighbors.
clients. server
load stateless
client firewall gateway
balancer server
Each layer cannot stateless
"see" beyond itâs server
immediate neighbor.
19. The optional 6th constraint, Code-on-Demand, allows the
client to request code from the server & execute it.
20. Add features to a
deployed client, which
provides for improved
extensibility and
configurability
client
stateless
server
code
Better user-perceived
performance and
efficiency
21. Now lets tackle the 4 parts of the 4th constraint,
Uniform Interface
31. state state
transition transition
state
transition transition
state state
32. â The name âRepresentational State Transferâ is intended
to evoke an image of how a well-designed Web
application behaves: a network of web pages (a virtual
state-machine), where the user progresses through the
application by selecting links (state transitions),
resulting in the next page (representing the next state of
the application) being transferred to the user and
rendered for their use.
-Roy Fielding
Architectural Styles and the
Design of Network-based Software Architectures
Chapter 6
39. home connect discover search my profile direct messages
google: lists
jackâs first favorite about
tweet
help
retweet
reply to keyboard
@jack shortcuts
turn off
retweets settings
report @jack
for spam sign out
add or remove
block @jack tweet to @jack Follow @jack @jack new tweet
from lists
80. I guarantee
hypermedia is
engine of app
I decide where state I craft the user
to click, aka experience, aka
change state. state diagram.
REST Interface
App Browser App
UI Server
User App Developer
81. The person who crafts the experience (state diagram)
and the app user have the REST interface between them.
85. We see the same pattern for syndication feeds.
86. I guarantee
hypermedia is
engine of app
state I craft stories,
I decide where
categories & related
to click, aka
media, aka state
change state.
diagram.
REST Interface
App Feed Reader Feed Content
User App Server Publisher
88. Interface
App
App 1
Developer 1
App API Server
App
User App 2
Developer 2
App
App 3
Developer 3
89. Interface
I craft the user experience,
I get no
aka state diagram.
App HATEOAS
App 1
I decide where Developer 1 respect.
to click, aka
change state.
App API Server
App
User App 2
Developer 2
App
App 3
Developer 3
90. The person who crafts the experience (state machine)
and the app user do not have the REST interface
between them.
91. And the hypermedia links are not given directly to the
app user at runtime.
107. I guarantee
hypermedia is
engine of app
I decide where state I craft a system of
to click, aka interrelated resources,
change state. aka state diagram.
REST Interface
App RESTful API API
API Server
User Client App Developer
?
110. â However, the style does not assume that all applications
are browsers. In fact, the application details are hidden
from the server by the generic connector interface, and
thus a user agent could equally be an automated robot
performing information retrieval for an indexing service,
a personal agent looking for data that matches certain
criteria, or a maintenance spider busy patrolling the
information for broken references or modified content
[39].
-Roy Fielding
Architectural Styles and the
Design of Network-based Software Architectures
Chapter 5
111. If youâre not going down the HATEOAS client path, should
you include links anyway?
112. 2. If you think including links in the API response will be
helpful for developers at design time, then go for it.
113.
114. But I wouldnât call it HATEOAS because those links are
probably not the engine of application state for the app
user at run time.
115. â If the engine of application state (and hence the
API) is not being driven by hypertext, then it
cannot be RESTful and cannot be a REST API.
Period. Is there some broken manual
somewhere that needs to be fixed?
-Roy Fielding
âREST APIs must be hypertext-drivenâ
Untangled: Musings of Roy T. Fielding
124. The Constraints of REST
1. Client-server
2. Stateless server
3. Cache
4. Uniform interface
a. Identification of resources
b. Manipulation of resources through representations
c. Self-descriptive messages
d. Hypermedia as the engine of application state
5. Layered System
6. Code-On-Demand (optional)
125. While keeping in mind how custom apps are built
by people using web APIs
126. Interface
App
App 1
Developer 1
App API Server
App
User App 2
Developer 2
App
App 3
Developer 3