As with any other technology, the Web will not automatically solve a business’s application and integration problems. But good design practices and adoption of good, well-tested, and widely deployed patterns will take us a long way in our journey to build great web services.
You’ll often hear the term web friendliness
used to characterize good application of web technologies. For example,
a service would be considered “web-friendly” if it correctly implemented
the semantics of HTTP
exposing resources through URIs. Since
GET doesn’t make any service-side state
changes that a consumer can be held accountable for, representations
generated as responses to
may be cached to increase performance and decrease
Leonard Richardson proposed a classification for services on the Web that we’ll use in this book to quantify discussions on service maturity. Leonard’s model promotes three levels of service maturity based on a service’s support for URIs, HTTP, and hypermedia (and a fourth level where no support is present). We believe this taxonomy is important because it allows us to ascribe general architectural patterns to services in a manner that is easily understood by service implementers.
The diagram in Figure 1-8 shows the three core technologies with which Richardson evaluates service maturity. Each layer builds on the concepts and technologies of the layers below. Generally speaking, the higher up the stack an application sits, and the more it employs instances of the technology in each layer, the more mature it is.
The most basic level of service maturity is characterized by
those services that have a single URI, and which use a single HTTP
example, most Web Services (WS-*)-based services use a single URI to
identify an endpoint, and HTTP
to transfer SOAP-based payloads, effectively ignoring the rest of the
We can do wonderful, sophisticated things with WS-*, and it is not our intention to imply that its level zero status is a criticism. We merely observe that WS-* services do not use many web features to help achieve their goals.
XML-RPC and Plain Old XML (POX) employ similar methods: HTTP
POST requests with XML payloads
transmitted to a single URI endpoint, with replies delivered in XML as
part of the HTTP response. We will examine the details of these
patterns, and show where they can be effective, in Chapter 3.
The next level of service maturity employs many URIs but only a
single HTTP verb. The key dividing feature between these kinds of
rudimentary services and level zero services is that level one
services expose numerous logical resources, while level zero services
tunnel all interactions through a single (large, complex) resource. In
level one services, however, operations are tunneled by inserting
operation names and parameters into a URI, and then transmitting that
URI to a remote service, typically via HTTP
Richardson claims that most services that describe themselves
as “RESTful” today are in reality often level one services. Level
one services can be useful, even though they don’t strictly adhere
to RESTful constraints, and so it’s possible to accidentally destroy
data by using a verb (
should not have such side effects.
Level two services host numerous URI-addressable resources. Such services support several of the HTTP verbs on each exposed resource. Included in this level are Create Read Update Delete (CRUD) services, which we cover in Chapter 4, where the state of resources, typically representing business entities, can be manipulated over the network. A prominent example of such a service is Amazon’s S3 storage system.
The most web-aware level of service supports the notion of hypermedia as the engine of application state. That is, representations contain URI links to other resources that might be of interest to consumers. The service leads consumers through a trail of resources, causing application state transitions as a result.
The phrase hypermedia as the engine of application state comes from Fielding’s work on the REST architectural style. In this book, we’ll tend to use the term hypermedia constraint instead because it’s shorter and it conveys that using hypermedia to manage application state is a beneficial aspect of large-scale computing systems.
 The suite of SOAP-based specifications and technologies, such as WSDL, WS-Transfer, WS-MetadataExchange, and so forth. Refer to http://www.w3.org/2002/ws/ as a starting point. We’ll discuss Web Services and their relationship to the Web in Chapter 12.