Learn about Resource-Oriented Architecture (ROA), why it is useful, and the best practices for using it.
Service-Oriented Architecture (SOA) and resource-oriented architecture (ROA) are architectural design patterns used to implement robust, scalable distributed application architectures. Distributed architectures are made up of components that are consumed across a network through well-defined interfaces. In ROA, these components are referred to as resources, while in SOA, they are referred to as services. This article presents an overview of resource-oriented architecture.
What is Resource-Oriented Architecture (ROA)?
Resource-Oriented Architecture (ROA) is a style of architecture that extends the REST architectural style and offers a broader, extensible, flexible, and transport-independent architecture. The Resource-Oriented Architecture (ROA) paradigm is built on the notion of a resource. A resource is a self-contained, identifiable entity having a state that can be assigned a uniform resource locator (URI). While a service represents the execution of a requested action, a resource represents a distributed component that is manageable through a consistent, standardized interface.
One of the characteristics of resource-oriented architecture is that they are transport-independent. So, there must be specific mechanisms for exposing resource-oriented services to the external world. When a consumer requests a Uniform Resource Locator (URL) and specifies an access method (e.g., GET, PUT, POST, & DELETE), the URL gets transformed into a relative internal URI. The access method is translated into action.
Resource-Oriented Architecture is modeled around just four concepts:
- Resources
- URIs
- Representations
- Links and Connectedness
Here are the four properties of Resource Oriented Architecture:
- Addressability
- Statelessness
- Connectedness
- A uniform interface
Resource Oriented Architecture: Resources
Resources are the building blocks of ROA; a resource is a logical representation of information. As an example, a student is an abstract collection of data points that may be represented in a variety of ways, including XHTML, JSON, and XML. A resource name comprises the following:
- The type of the resource
- Resource identifier
- The resource name of the parent
- The name of the API service.
A resource is the most crucial abstraction of information in REST or RESTful architecture. The term “resource” refers to any identifiable information. Such information can be a document, a computer, a car, a temporal service (such as “today’s weather in Ohio”), a collection of other resources, a person, a student, and so on.
Each immutable resource representation is identifiable by a relative Universal Resource Indicator (URI), and it may include connections to other resources as well as other immutable resources. Note that a resource can have multiple URIs as well.
Each resource should have the following characteristics:
- Is unique
- It must have a minimum of one representation
- It has attributes, the schema that can be accessed and can provide a context
Uniform Resource Identifier (URI)
A Uniform Resource Identifier (URI) is a sequence of characters that contains the name and address of a resource and is used to identify a logical or a physical resource. Note that a resource must have one or more URIs. Without a URI, a piece of information is not considered a resource since it cannot be referred to or accessed. You can use URIs to identify anything such as real-world objects, web pages, books, etc.
Here’s an example of a URI:
Syntax: : Example: http://payroll/employee/1234
The following table illustrates how relative URI for a resource can be specified:
- Action
Relative URI
Purpose - Read
/student/3
Read a student record having Id as 3. - Delete
/student/4
Delete a student record having Id as 4.
Features of Resource-Oriented Architectures ROA
Here are the four basic properties of Resource-Oriented Architectures:
Addressability
Addressability is an essential feature of resource-oriented architectures. An application can be considered addressable if it publishes the interesting aspects of its data set as service endpoints. These services can be in turn, be used to work with the application’s data. Since resources in ROA are exposed using URIs, an application should expose its data using URIs.
Statelessness
Statelessness is yet another feature of resource-oriented architectures, implying that every HTTP request in this architecture happens in isolation. In other words, when the client requests a resource to the server, the client must provide every piece of information that the server might need for the request to be successful. The server never stores information from the previous requests, i.e., no state information is stored at the server. If the server needs information from an earlier request to process a request, the client must send that information again in another request.
Connectedness
In Resource-Oriented Architecture, representations are hypermedia: documents containing both data and links to other resources. RESTful web services follow the Hypermedia As The Engine Of Application State (HATEOS) principle. This is a principle in which the format of data influences the transition states in your application. The links to other resources are embedded inside the response, but they can differ for the same resource based on its current state.
One of the most significant characteristics of the web is its interconnectedness. i.e., virtually all of the information on the internet is linked together via hyperlinks. A hyperlink can be used to connect any resource that is accessible on the internet to another resource. An application built on ROA should have all of its resources linked to one another and vice versa. When we select the appropriate representation for a resource, we may achieve connectedness in an application.
A Uniform Interface
You should have a set of well-defined methods that can manipulate the resources in your application. For example, HTTP provides the following common operations you might typically need to perform in any application:
HTTP GET – Retrieve a resource
HTTP POST – Create new resources
HTTP PUT – Modify an existing resource
HTTP DELETE – Delete an existing resource
HEAD and OPTIONS HTTP Methods
Here are two other important HTTP methods you should know:
HTTP HEAD – This is used to retrieve metadata-only representation of a resource
HTTP OPTIONS – This is used to check which HTTP methods are supported by a particular resource
Summary
A resource-oriented architecture is stateless and revolves around a resource. A URI is used to identify each resource. You can always have several copies of the same resource on your computer at the same time. You can also have multiple URIs for one resource.
