Resource Oriented Architecture
This is a short introduction to the Resource Oriented Architecture (ROA)
It is recommended to read The Hierarchy and the Graph for a less technical introduction to the topic.
Web services are software implementations that make resources available on the Internet (or World Wide Web). The resource can be any type of data from a simple text, HTML page, XML document, image or even raw data. Human beings (or rather their software) can to fetch, parse (read) and use this data for presentation but also for calculation. Read/write web services allow a user (or rather their software) to modify the data on the web server, in many cases contained in a database. Complex Web Services can perform highly specialized types of calculation gearde towards specific domains.
A more strict interpretation of the concept Web Service defines it is a Web resource that has been designed for programmable access. It allows other machines (the clients) to access and use its features in a well-defined manner.
In the early days of the Internet so called Screen Scraper software was used to harvest information from web sites that were implemented in a way that only humans could "read" them. This software used the concept behind HTML which is a well known and structured syntax to extract information and reuse in other contexts. This made the Web itself one big de facto Web Service. But this is a notoriously brittle solution, and therefore unsatisfactory. What distinguishes a Web Service from a Web Site is that it is purposely designed for access by client software.
The case for Web Services designed according to a Resource-Oriented Architecture (ROA) was presented by Leonard Richardson and Sam Ruby in their book RESTful Web Services (2007, O'Reilly Media Inc.).
The fundamental idea is that the basic, well-understood, and well-known technologies of the current web (HTTP, URI and XML) should be used according to their design principles. This facilitates the design of Web Services that have simple and coherent interfaces, and which are easy to use and maintain. Such web services will also be easier to optimize for working with the existing infrastructure of the web. The design principles of the web technologies are summarized by Roy Fielding's notion of Representational State Transfer (REST) in his Ph.D. thesis Architectural Styles and the Design of Network-based Software Architectures (2000).
The Resource-Oriented Architecture (ROA) consists of four concepts:
- Their names (URIs)
- Their representations
- The links between them (What an irony that the Wikipedia article on the ROA is tagged as an "orphan" as few or no other articles link to it).
and four properties:
- A uniform interface
Websites should be designed following these concepts and properties. All URLs (the correct term in other contexts is Uniform Resource Identifier (or URI)) should be designed for clarity and consistency. The representations (HTML and XML) should be well formed and structured. Especially HTML allows for many exceptions and is frequently being "misused" to achieve design features using structuring elements. The design principle to follow here is to separate form and content. All representations should be strongly linked. It should always be possible to navigate through the representation of all entities just by following links and this should be true for both the HTML and XML representations.
One important benefit of the ROA is a low barrier of entry. Both using Web Services provided by others from the client side and implementing the server side (exposing resources to others) should need as little overhead as possible. If many different, special-purpose technologies and standards need to be mastered, then the overhead in terms of time and effort may well become prohibitive. Since ROA uses only the well-known basic technologies of the web, it is likely to be much easier to use than the SOAP approach, which has its own unique and extensive technology stack.
Isomorphic representations allow a potential user to grasp the design of the programmatic web service simply by browsing the human web site. By noting the URLs and looking at the HTML and corresponding XML documents, it becomes much simpler to write a client program to automate the analysis the user has in mind.
The Resource Perspective
The two concepts 'Resource' and 'Service' are related but come from different levels of perspective. Resources have representations for example HTML documents. These representations get transmitted from the server to the client. The server does not have to "keep track" of the client as it will always receive a completely self contained representation back. The client does not have to know whether the server did everything correctly (imagine that the Internet connection had a hickup) and can be sure that whatever it does will always result in exactly one action of the server and not destroy what was previously sent (this concept is called Idempotence). The client does not need to keep track of which instance of a server it has talked to. This allows for highly scalable architectures.
...to be continued