1.
1

2.
REST
Web Applications made Web —err… right?
2
Almost all quotes presented here are from
Roy T. Fielding —anything new so far?

3.
–Roy T. Fielding
“I think most people just make the mistake that it
should be simple to design simple things. In
reality, the effort required to design something
is inversely proportional to the simplicity of
the result. As architectural styles go, REST is
very simple.”
3

4.
4

5.
5

6.
–Roy T. Fielding
“… 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."
6

7.
–Theodor H. Nelson
“By ‘hypertext,’ I mean non-sequential writing —
text that branches and allows choices to the
reader, best read at an interactive screen. As
popularly conceived, this is a series of text
chunks connected by links which offer the
reader different pathways.”
7

8.
–Jeffrey Conklin
“Hypertext is a computer-supported medium
for information in which many interlinked
documents are displayed with their links on a
high-resolution computer screen.”
8

9.
“To some extent, people get REST wrong
because I failed to include enough detail on
media type design within my dissertation. […]
Likewise, I suspect a lot of people get it
wrong because they read only the Wikipedia
entry on the subject, which is not based on
authoritative sources.”
–Roy T. Fielding
9

10.
• 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.
10

11.
• 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’s 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.
11

12.
• 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.
• Failure here implies that out-of-band information
is driving interaction instead of hypertext.
12

13.
• 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.
13

14.
• 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 the client’s
knowledge of media types and resource communication
mechanisms, both of which may be improved on-the-fly.
14

15.
Rest
• Representational
• State
• Transfer
of
• Resources
http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http15

16.
Resources
• The key abstraction of information in REST is a
resource. Any information that can be named can
be a resource: a document or image, a weather
service (e.g. "today's weather in Los Angeles"), a
collection of other resources, a non-virtual object
(e.g. a person), and so on. In other words, any
concept that might be the target of an author's
hypertext reference must fit within the definition of a
resource. A resource is a conceptual mapping to
a set of entities, not the entity that corresponds
to the mapping at any particular point in time.
16

17.
Representations
• REST components perform actions on a resource by
using a representation to capture the current or
intended state of that resource and transferring that
representation between components. A representation
is a sequence of bytes, plus representation metadata to
describe those bytes. Other commonly used but less
precise names for a representation include: document, file,
and HTTP message entity, instance, or variant.
• A representation consists of data, metadata describing
the data, and, on occasion, metadata to describe the
metadata (usually for the purpose of verifying message
integrity).
17

18.
State
• A resource within constraints:
• OFFSET, LIMIT, PAGE
• point in time, both times: valid and transaction
times
• …
• Resources as State Machines
18

19.
Transfer
• Erm… Well…
“About your cat, Mr. Schrödinger—I have good news and bad news.”
http://www.newyorker.com/magazine/2015/03/30/a-loss-for-words19

20.
• http://example.com/rest/v1.1.0/en/resource.js
20

21.
• http://example.com/rest/v1.1.0/en/resource.js
21

22.
• Web Applications/Services
• Rest
• RESTFul
• HATEOAS
• Hypermedia API
22

23.
JSON vs XML
• XML has more mature specification: it is possible
to provide Rest using only XML and its
counterparts: XForms, XSD, WSDL, XSLT, XML
Events: declarative programming —NO
procedural code. It even has a name: XRX.
• Reinventing the wheel can be good, but JSON is
still to evolve —json schema, hyperschema and
linked data…— where XML already rocks.
23

24.
• DDD: Domain Driven
Design
• Naked Objects
—or True MVC at least
according to Trygve
Reenskaug
• Good OO Design —
anaemic domain is the
Dalek of Software
Engineering
“every time a flag is born
an unicorn dies”
24
• What is really hard is to write good software