communication must be stateless in nature, as in the client-stateless-server
(CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to
server must contain all of the information necessary to understand the request,
and cannot take advantage of any stored context on the server. Session state is
therefore kept entirely on the client.
Visibility is improved because a monitoring system does not have to look beyond
a single request datum in order to determine the full nature of the
request. Reliability is improved because it eases the task of recovering from
partial failures [133]. Scalability is improved because not having to store
state between requests allows the server component to quickly free resources,
and further simplifies implementation because the server doesn’t have to manage
resource usage across requests.
central feature that distinguishes the REST architectural style from other
network-based styles is its emphasis on a uniform interface between components
REST is defined by four interface constraints: identification of resources;
manipulation of resources through representations; self-descriptive messages;
and, hypermedia as the engine of application stat
, the layered system style allows an architecture to be composed of hierarchical
layers by constraining component behavior such that each component cannot “see”
beyond the immediate layer with which they are interacting
REST provides a hybrid of all three options by focusing on a shared
understanding of data types with metadata, but limiting the scope of what is
revealed to a standardized interface
representation consists of data, metadata describing the data, and, on occasion,
metadata to describe the metadata (usually for the purpose of verifying message
integrity). Metadata is in the form of name-value pairs
REST interface is designed to be efficient for large-grain hypermedia data
transfer, optimizing for the common case of the Web, but resulting in an
interface that is not optimal for other forms of architectural interaction
REST ignores the details of component implementation and protocol syntax in
order to focus on the roles of components, the constraints upon their
interaction with other components, and their interpretation of significant data
elements.
When a link is selected, information needs to be moved from the location where
it is stored to the location where it will be used by, in most cases, a human
reader. This is unlike many other distributed processing paradigms [6, 50],
where it is possible, and usually more efficient, to move the “processing agent”
(e.g., mobile code, stored procedure, search expression, etc.) to the data
rather than move the data to the processor.
REST components communicate by transferring a representation of a resource in a format matching one of an evolving set of standard data types, selected dynamically based on the capabilities or desires of the recipient and the nature of the resource
information that can be named can be a resource: a document or image, a temporal 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.
are two distinct resources, even if they both map to the same value at some
point in time. The distinction is necessary so that both resources can be
identified and referenced independently
similar example from software engineering is the separate identification of a version-controlled source code file when referring to the “latest revision”, “revision number 1.2.7”, or “revision included with the Orange release.”
connectors present an abstract interface for component communication, enhancing simplicity by providing a clean separation of concerns and hiding the underlying implementation of resources and communication mechanisms. The
user agent uses a client connector to initiate a request and becomes the ultimate recipient of the response. The most common example is a Web browser, which provides access to information services and renders service responses according to the application needs
origin server uses a server connector to govern the namespace for a requested resource. It is the definitive source for representations of its resources and must be the ultimate recipient of any request that intends to modify the value of its resources. Each origin server provides a generic interface to its services as a resource hierarchy. The resource implementation details are hidden behind the interface
proxy component is an intermediary selected by a client to provide interface encapsulation of other services, data translation, performance enhancement, or security protection
gateway (a.k.a., reverse proxy) component is an intermediary imposed by the network or origin server to provide an interface encapsulation of other services, for data translation, performance enhancement, or security enforcement
The model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations
Requests and responses have the appearance of a remote invocation style, but REST messages are targeted at a conceptual resource rather than an implementation identifier.
REST works well because it does not limit the implementation of resources to certain predefined models, allowing each application to choose an implementation that best matches its own needs and enabling the replacement of implementations without impacting the user
The interaction method of sending representations of resources to consuming components has some parallels with event-based integration (EBI) styles. The key difference is that EBI styles are push-based. The component containing the state (equivalent to an origin server in REST) issues an event whenever the state changes, whether or not any component is actually interested in or listening for such an event
REST style, consuming components usually pull representations. Although this is less efficient when viewed as a single client wishing to monitor a single resource, the scale of the Web makes an unregulated push model infeasible
REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems
REST was originally referred to as the “HTTP object model,” but that name would often lead to misinterpretation of it as the implementation model of an HTTP server.
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.
Forcing the interface definitions to match the interface requirements causes the
protocols to seem vague, but that is only because the interface being
manipulated is only an interface and not an implementation. The protocols are
specific about the intent of an application action, but the mechanism behind the
interface must decide how that intention affects the underlying implementation
of the resource mapping to representations.
Information hiding is one of the key software engineering principles that motivates the uniform interface of REST. Because a client is restricted to the manipulation of representations rather than directly accessing the implementation of a resource, the implementation can be constructed in whatever form is desired by the naming authority without impacting the clients that may use its representations.
A resource does not always map to a singular file, but all resources that are
not static are derived from some other resources, and by following the
derivation tree an author can eventually find all of the source resources that
must be edited in order to modify the representation of a resource
The resource is a conceptual mapping – the server receives the identifier
(which identifies the mapping) and applies it to its current mapping
implementation (usually a combination of collection-specific deep tree traversal
and/or hash tables) to find the currently responsible handler implementation and
the handler implementation then selects the appropriate action+response based on
the request content
Cookies also violate REST because they allow data to be passed without
sufficiently identifying its semantics, thus becoming a concern for both
security and privacy. The combination of cookies with the Referer [sic] header
field makes it possible to track a user as they browse between sites.
Likewise, the use of cookies to identify a user-specific “shopping basket”
within a server-side database could be more efficiently implemented by defining
the semantics of shopping items within the hypermedia data formats, allowing the
user agent to select and store those items within their own client-side shopping
basket, complete with a URI to be used for check-out when the client is ready to
purchase.
, placing the application state on the client-side reduces the server’s control over consistent application behavior, since the application becomes dependent on the correct implementation of semantics across multiple client versions
REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application stat
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
Hateoas : the hypermedia os the way the state is communicated from the client to the server
REST concentrates all of the control state into the representations received in response to interactions. The goal is to improve server scalability by eliminating any need for the server to maintain an awareness of the client state beyond the current request. An application’s state is therefore defined by its pending requests, the topology of connected components (some of which may be filtering buffered data), the active requests on those connectors, the data flow of representations in response to those requests, and the processing of those representations as they are received by the user agent.
Since REST-based architectures communicate primarily through the transfer of representations of resources, latency can be impacted by both the design of the communication protocols and the design of the representation data formats. The ability to incrementally render the response data as it is received is determined by the design of the media type and the availability of layout information (visual dimensions of in-line objects) within each representation.
next control state of an application resides in the representation of the first requested resource, so obtaining that first representation is a priority. REST interaction is therefore improved by protocols that “respond first and think later.”
The state is user agent’s business and may even overlap several servers ontologies
allows the user to directly manipulate the state (e.g., a Web browser’s history), anticipate changes to that state (e.g., link maps and prefetching of representations), and jump from one application to another (e.g., bookmarks and URI-entry dialogs).
model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations. Not surprisingly, this exactly matches the user interface of a hypermedia browser.
Manipulation of resources through representations – The resources should have uniform representations in the server response. API consumers should use these representations to modify the resources state in the server.
Self-descriptive messages – Each resource representation should carry enough information to describe how to process the message. It should also provide information of the additional actions that the client can perform on the resource
Hypermedia as the engine of application state – The client should have only the initial URI of the application. The client application should dynamically drive all other resources and interactions with the use of hyperlinks.
The resource representations are consist of:the datathe metadata describing the dataand the hypermedia links that can help the clients in transition to the next desired state
Hypertext (or hypermedia) means the simultaneous presentation of information and controls such that the information becomes the affordance through which the user (or automaton) obtains choices and selects actions.Remember that hypertext does not need to be HTML (or XML or JSON) on a browser. Machines can follow links when they understand the data format and relationship types.— Roy Fielding
Roy: I talk about it because the initial reaction to using REST for
machine-to-machine interaction is almost always of the form “we don’t see a
reason to bother with hypermedia — it just slows down the interactions, as
opposed to the client knowing directly what to send.” The rationale behind
decoupling for evolvability is simply not apparent to developers who think they
are working towards a modest goal, like “works next week” or “we’ll fix it in
the next release”.
If developers can conceive of their systems being used for a much longer time,
then we can escape their own preconceptions about how it will need to change
over time. We can then work back from decades to years (how long until you don’t
know your users?) or even months (how long until you’ve lost control over client
deployment?).
hypermedia as the engine of application state" is a REST constraint. Not an
option. Not an ideal. Hypermedia is a constraint. As in, you either do it or you
aren’t doing REST. You can’t have evolvability if clients have their controls
baked into their design at deployment. Controls have to be learned on the
fly. That’s what hypermedia enables.
Hypermedia allows application controls to be supplied on demand, but we also
need to be able to adapt the clients’ understanding of representations
(understanding of media types and their expected processing). That is where
code-on-demand shines.
I’ve read several articles about REST, even a bit of the original paper. But
I still have quite a vague idea about what it is. I’m beginning to think that
nobody knows, that it’s simply a very poorly defined concept.
After reading Fielding’s dissertation, I
realized that the much more interesting story here is how Fielding’s ideas came
to be so widely misunderstood.
Fielding’s dissertation (titled “Architectural Styles and the Design of
Network-based Software Architectures”) is not about how to build APIs on top of
HTTP but rather about HTTP itself.
his dissertation presents REST as a
distillation of the architectural principles that guided the standardization
process for HTTP/1.1. Fielding used these principles to make decisions about
which proposals to incorporate into HTTP/1.1
Fielding establishes this taxonomy to emphasize that different constraints are
appropriate for different applications and that this last group of constraints
were the ones he felt worked best for HTTP.
deep, deep irony of REST’s ubiquity today. REST gets blindly used
for all sorts of networked applications now, but Fielding originally offered
REST as an illustration of how to derive a software architecture tailored to
an individual application’s particular needs.
He warns, almost at the
very beginning of the dissertation, that “design-by-buzzword is a common
occurrence” brought on by a failure to properly appreciate software
architecture
Some architectural styles are often portrayed as “silver bullet” solutions
for all forms of software. However, a good designer should select a style
that matches the needs of a particular problem being solved.5
Fielding later points out, it incorporates trade-offs that may not be
appropriate unless you are building a distributed hypermedia application:
REST is designed to be efficient for large-grain hypermedia data transfer,
optimizing for the common case of the Web, but resulting in an interface that
is not optimal for other forms of architectural interaction.6
The constraints
that REST imposes were carefully chosen to solve this anarchic scalability
problem. Web service APIs that are public-facing have to deal with a similar
problem, so one can see why REST is relevant there.
Yet today it would not be
at all surprising to find that an engineering team has built a backend using
REST even though the backend only talks to clients that the engineering team
has full control over.
given that Fielding’s dissertation was all about avoiding silver bullet
software architectures, how did REST become a de facto standard for web
services of every kind?
Adopting
REST’s constraints makes some sense, especially for public-facing APIs that do
cross organizational boundaries and thus benefit from REST’s “uniform
interface.”
Fielding’s dissertation (titled “Architectural Styles and the Design of
Network-based Software Architectures”) is not about how to build APIs on top of
HTTP but rather about HTTP itself.
you could sum up the part of the dissertation where
Fielding introduces REST as, essentially, “Listen, we just designed HTTP, so if
you also find yourself designing a distributed hypermedia system you should
use this cool architecture we worked out called REST to make things easier.”
Fielding makes clear that REST is intended as a solution for the scalability
and consistency problems that arise when trying to connect hypermedia across
the internet, not as an architectural model for distributed applications in
general.
