Resource-oriented architecture

In software engineering, a resource-oriented architecture (ROA) 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 (discrete pieces of code and/or data structures) 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 , 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.^[1][2]

Guidelines for clarification

The Resource Oriented Architecture as documented by Leonard Richardson and Sam Ruby^[3] 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 (possibly an infinite number of them), one for each Resource (any resources in your applications should be unambiguously accessible via a unique URI)
• Cookies representing IDs into a server side session are not RESTful
• Combinations of resources (i.e. a particular account viewing the results of a particular database query) can be RESTful if (and only if) the combination can be represented as a URI.
• RESTful URIs should facilitate "cut & paste" (that's the notion of "transfer" of the "representational state")

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

Why the Web?

While REST is a set of architectural guidelines applicable to various types of computing infrastructures, Resource Oriented Architecture (ROA) 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 (arguably futile) to reach a 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.^[4]

See also

References

Bibliography