外文文献翻译_面向资源的架构

Resource-Oriented Architecture: The Rest of REST

Series Introduction

Think for a moment, if you can, back to a time before the Web. Imagine trying to

explain the impending changes to your hapless contemporaries. It is likely they would

simply not be able to fathom the impacts that the Web's emergence would have on

nearly every aspect of their lives. In retrospect, it feels like a tsunami caught us off-

guard and forever altered the landscape around us. The reality is more pedestrian,

however. It was a deliberate series of technical choices that built upon each other that

is that they have been in the works for years and are just now producing tangible

results. This new wave is about a Web that has evolved beyond documents into Webs

of Data, both personal and private. We will no longer focus on information containers,

but on information itself and how it is connected.

This wave has been in the works for years and is again being driven by the

deliberate adoption of specific choices and technologies. These choices are combining

to solve the problems caused by the inexorable march of technological change,

business flux, new and varied data sources and the ubiquitous, expensive and failure-

prone efforts that have cost millions and delivered insufficient value. Web Services

and Service-Oriented Architectures (SOA) were supposed to be part of the answer, but

of Data with our own, privately held data. The incremental adoption of these

technologies is yielding new capabilities that will, in turn, unlock further capabilities.

This is the first article in a new series to highlight the evolution of information-

oriented systems that got us to where we are and provide a roadmap to where we are

going. Despite what it may seem on the surface, these choices are neither ad hoc nor

esoteric, but rather foundational decisions based on a long tradition of academia and

applied engineering.

We will start by revisiting the REpresentational State Transfer (REST)

architectural style. Oft quoted and even more often misunderstood, this manner of

building networked software systems allows us to merge our documents, data and

After we present the basics, we will walk through a variety of successful efforts

building on these technologies and then return to reclaiming the vision promised to us

by proponents of Web Services technologies. We will describe a process where we

can achieve something of a Unified Theory of Information Systems; one that not only

handles, but embraces the kind of technical and social change that has been painful

and intractable to manage in the past.

There has been too much hype surrounding the Semantic Web, but there have

adoption of standards that are designed to facilitate change.

The first step, is to embrace a common naming scheme for all aspects of our

infrastructure. A Service-Only Architecture usually ignores the data that flows through

it. At the end of the day, our organizations care about information first and foremost.

REST and the Web Architecture puts this priority up front and lays the foundation for

the remainder of our discussion.

The Rest of REST

It has become fashionable to talk about the REpresentational State Transfer

(REST) as something of a weapon in the War On Complexity. The enemies in this

technology of convenience; a simple solution for invoking Web Services through

URLs. The management of information resources is not the same thing as invoking

arbitrary behavior. This confusion leads people to build "RESTful" solutions that are

neither RESTful, nor good solutions.

REST derives its benefits as much from its restrictions as it does its resultant

flexibility. If you read Dr. Roy Fielding's thesis (which you are encouraged to do), you

will learn that the intent was to describe how the combination of specific architectural

constraints yields a set of properties that we find desirable in networked software

systems. The adoption of a uniform interface, the infamous Uniform Resource

Locator (URL), contributes to the definition of REST, but is insufficient to define it.

You retrieve information by issuing GET requests to URLs, you create or update via

POST and PUT, and remove information via DELETE requests.

This summary is not incorrect, but it leaves too much out. The omissions yield

degrees of freedom that unfortunately often allow people to make the wrong

decisions. In this gap, people create URLs out of verbs which eliminates the benefit of

having names for "things". They think REST is just about CRUD operations. They

create magical, unrelated URLs that you have to know up front how to parse, losing

foundation of Web architecture, the application of the remaining technologies of the

Semantic Web will yield unprecedented power in how we interact with each other as

individuals, governments, organizations and beyond. This is why we begin with a

deeper dive into the parts of REST that many people do not understand and therefore

do not discuss. These topics include the implications of:

URLs as identifiers

Freedom of Form

Logically-connected, Late-binding Systems

Hypertext as the Engine of State Transfer (HATEOS)

First?" skit on a daily basis. Having names gives us the ability to disambiguate and

identify something we care about within a context. Having a name and a common

context allows us to make reference to named things out of that context.

The Uniform Resource Identifier (URI) is the parent scheme. It is a method for

encoding other schemes depending on whether we want them to include resolution

information or not. Librarians and other long-term data stewards like names that will

not change. A Uniform Resource Name (URN) is a URI that has no location

information in it; nothing but name is involved. The good news is that these names

will never break. The bad news is that there is no resolution process for them. An

example of a URN is an ISBN number for a book:

so we could resolve them. But anyone who has been handed a broken link knows we

want longer-lived names for really important stuff. Looking at our history of using

URLs, we have done some silly things when we created ones such as:

http://someserver.com/cgi-bin/foo/bar.pl

http://someserver.com/ActionServlet?blah=blah

http://someserver.com/foo/bar.php

The problem with these URLs is that the technology used to produce a result is

Despite being fragile, the URL scheme does allow us to disambiguate

information references in a global context.

http://company1.com/customer/123456

is distinct and distinguishable from

http://company2.com/customer/123456

in ways that a decontextualized identifier like '123456' is not.

To ground the concept into a larger information systems framework, you can

think of a URL as a primary key that is not specific to a particular database. We can

make references to an item via its URL in dozens of different databases, documents,

applications, etc. and know that we are referring to the same thing because we have a

services (REST!)

concepts (people, organizations, domain-specific terms)

We do not need to come up with a different mechanism to refer to each different

category of things. A careful application of some specific guidelines allows us to blur

the distinctions between these things which brings us to the last point for now about

URLs. Not only are these names useful in order to refer to information we care about,

but systems that receive these references can simply ask for them. The 'L' in URL

(locator) gives us the capacity to resolve the thing, not knowing anything else about it.

We can usually invoke the same basic operations on everything we can name. Issuing

a GET request to a URL representing a document, some data, a service to produce that