In software engineering, a resource-oriented architecture is a
style of software architecture and programming paradigm for designing and
developing software in the form of resources with "RESTful" interfaces.
These resources are software components which can be reused for different
purposes. ROA design principles and guidelines are used during the phases of
software development and system integration.
REST, or Representational State Transfer [1], describes a series of architectural
constraints that exemplify how the web's design emerged. Various concrete
implementations of these ideas have been created throughout time, but it has been
difficult to discuss the REST architectural style without blurring the
lines between actual software and the architectural principles behind it.
In Chapter 5 of his thesis, Roy Fielding documents how the World Wide Web is
designed to be constrained by the REST series of limitations. These are still
fairly abstract and have been interpreted in various ways in designing
new frameworks, systems, and websites. In the past, heated exchanges have been
made about whether RPC-style REST architectures are RESTful.
Guidelines for clarification The Resource Oriented Architecture as
documented by Leonard Richardson and Sam Ruby gives concrete advice on specific
technical details. Naming these collections of guidelines "Resource
Oriented Architecture" may allow developers to discuss the benefits of an
architecture in the context of ROA. Example guidelines include:
Query string parameters in the URI are appropriate if they are inputs to a
Resource which is an algorithm Otherwise, these values should be placed
into the path component of the URI Prefer pragmatic uses of putting data
into URI, instead of using HTTP Headers A resource can use file extension in the
URI, instead of Content-Type negotiation RPC-style APIs are avoided in favor of
Resources and protocols A representation of a resource should
have many links to the other Resources in the application, so that a client can
discover state transitions URI templates provide the technology
behind specifying families of URI to clients .
Common guidelines Some guidelines are already common
within the larger REST communities: Applications should expose many URIs,
one for each Resource Cookies representing IDs into a server
side session are not RESTful Combinations of resources can be RESTful
if the combination can be represented as a URI.
RESTful URIs should facilitate "cut & paste"
Existing frameworks RESTful Web Services discusses many
software frameworks which provide some or many features of the ROA. These
include /db - constructs resource oriented
architecture from relational databases Django
TurboGears Flask
EverRest JBoss RESTEasy
JBoss Seam Apache Wink
Jersey NetKernel
Recess Restlet
Ruby on Rails Symfony
Yii2 Play Framework [2]
Why the Web? While REST is a set of architectural
guidelines applicable to various types of computing infrastructures, Resource
Oriented Architecture is only coupled with the web. This architecture is
therefore useful mostly to businesses that consider the web as the
computing/publishing platform of choice. The power of the web seems to mostly
reside in its ability to lower the barriers to entry for human users who
may not be highly trained in using computing machinery. As such, the web
widens the market reach for any business that decides to publish some of its
content in electronic format. On the web, such published content is
regarded as a web resource. The world of representations
Humans live in the world of representations. Representation, as a
concept, is an attempt to reach certain acceptable level of objectivity.
For example, if a person wants to buy a house, that person needs to qualify for
a mortgage. If that person explains to the mortgage broker that he has
$50,000.00 cash available for the down payment toward purchasing the house, the
broker will not go ahead and approve the mortgage, even though the quoted amount
would be fully satisfactory. What the mortgage broker needs is a more
objective argument that would reassure the issuer that the party asking for the
mortgage does indeed have enough money for the down payment.
But how is the issuer to go about obtaining the more objective proof?
Certainly not by going directly into the applicant's safety vault and counting
the money deposited there. Instead, the issuer is simply expecting to receive a
representation of that person's balance in his bank account.
That representation projects a sufficient illusion of objectivity, so
that the involved parties could sufficiently relax and that the business
transaction can eventually take place. In the same manner, any transaction that
transpires on the web is based on the similar representational logic. The
actual resource is never being touched. Instead, various representations of the
said resource are being prepared, rendered, and shipped to the clients for
consumption. Same as in the real world, where the mortgage issuer will never
actually touch client's money, but will instead be satisfied with a mere piece
of paper representing the balance, resources on the web never get to be
directly manipulated by the clients. See also
References Bibliography