Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

REST for Java developers, Part 4: The future is RESTful

The REST architectural style in the Semantic Web

By Brian Sletten, JavaWorld.com, 04/02/09

Page 2 of 5

RESTful URLs

A URL to a resource such as http://server/order/1234 provides a name for some information -- in this case, an order. We have had order IDs for as long as we have had order-processing systems. What is different about the Web and what is different about REST is that this identifier is unique, global, and resolvable. Do you want to look at what was in this order? Well, ask for it! This kind of name not only allows us to distinguish one order from another; it is also (as you'll see in the next section) the interface to that resource.

RESTful URLs do not have to refer just to raw data in databases, however. You can also create new URLs to refer to higher, layered processing, and business-specific concepts. How about open orders? The biggest orders of the past year? Every order from a particular customer? Orders that failed because your company could not meet the service-level agreement for particular customers? These concepts are all tremendously useful to a business, and being able to name and ask for this information directly is a powerful, efficient, and liberating process. Learning the URL schemes does not need to be onerous. By following some general guidance and understanding the term HATEOS, you can make it easy to browse for information. And by applying a reasonable metadata standard to the description of your resources, you can make the discovery process easier over even very large URL spaces.

HATEOS

One of the least-understood parts of REST and Fielding's thesis is the thinking behind the phrase hypertext as the engine of state transfer (HATEOS). The breadth and depth of this misunderstanding provoked Fielding to issue a recent series of justified but cranky blog entries reminding people about this point. HATEOS can be a fairly nuanced concept, but its direct consequences are pretty straightforward.

Consider the Web again. The dominant means of experiencing it is through a browser. You type in a URL to a site, and the browser issues a request via a specific protocol (usually HTTP) for the resource. At that point, the resource representation (usually an HTML document) is transferred back to your application along with metadata that indicates to the browser how to interpret it. Embedded in the result are links to one or more other pages, resources, images, and so on. Based on the content type (application/html), the browser understands how to parse it. It can find these embedded references and allow you to invoke them transparently by clicking through. Each new result is requested, interpreted, and rendered. As you probably well know, this simple process can engage you for hours!

The point of this thought experiment is to remember what HATEOS means in practice. In short:

• REST is not equivalent to HTTP even though HTTP is the dominant application protocol used. REST works with other schemes as well.
• The uniform interface is the interface. Because of its constraints, REST does not have the same need as other approaches for service-description languages. The URL for a resource is how you interact with it using a semantically constrained set of verbs. Approaches like the Web Application Description Language (WADL) are unnecessary and confuse the issue. REST is not about arbitrary behavior; it is about manipulating information resources.
• Resources -- even subresources -- should be linkable. Do not return just blobs of data or collections of "dead" data. Collections of links are perfectly reasonable results that your client should understand.
• You can indicate processing hints to the client by tagging resources with appropriate content types. A client knows how to parse HTML, render an image, or play a sound file. Nonbrowser clients or sufficiently available plug-in technologies allow the whole system to be extended. Content negotiation allows the same resource to be requested in different formats as needed. You can define your own content types using the MIME approach to indicate how clients should interpret your data if standard types don't apply.

Resource description and discovery

It is easy to imagine wanting to describe resources beyond simple MIME types, however. The line between the Web and the Semantic Web becomes blurry (and rightly so) when you start moving into metadata descriptions. There is a tremendous amount more to the Semantic Web than metadata, but that is how people usually come to it. What kind of metadata would you want for resources? What wouldn't you like to know? Who created it? When was it created? For what purpose is it allowed? Intended? What is it about conceptually? Where can you find more information about it? Is it associated with a particular geographical location?

SOAP-based Web services have Universal Description Discovery & Integration (UDDI) to describe and query metadata about them, but that is a broken technology that's painful to employ (and few organizations actually do). The W3C's Resource Description Framework (RDF) is lighter weight and reusable, and it supports the open world assumption -- that is, anyone can say anything about anything. There is never a finished state so Semantic Web applications must always accept new facts. Many existing metadata and reasoning systems would lock the universe of discourse down with the closed world assumption: anything not specified is not valid or true. This assumption makes it easier to build reasoners about these systems but is not useful in a vibrant, global, and constantly evolving environment like the Web.

RDF provides the substrate on which most other Semantic Web technologies are built. In general, you express relationships about URI-addressable resources (a perfect fit for describing RESTful service metadata!). The key point to remember is that what makes all of this different is the Web, not the semantics. There have been knowledge systems for years, but being able to express arbitrary relationships among linked information resources in an extensible way is the real game changer.