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 5 of 5

URI curation

Anyone who has been around the Web for a while is likely to protest that URLs are fragile. Links break. This is true, but deliberate choice of URLs based on logical names and relationships that will endure can go a long way toward solving this problem.

By following some specific guidelines, you can create longer-lived URLs that will not break as easily. Information to avoid within URLs includes:

• Specific technologies (servlet, .php, etc.): Nobody cares what you used to produce it. If you change what you use, you break the links.
• Specific formats (if you can avoid them): Use MIME types and content-negotiation instead. Links are more flexible and reusable if the XML and HTML versions of a resource are the same instead of being differentiated by the .xml and .html suffixes.
• Frequently changing structures (such as organizational charts) : Your org chart will change, Cool URIs do not.
• Items in "draft" or "beta" status: By definition, something going through a review draft will come out of it. Use metadata to indicate this status, rather than encoding it in the resource definition. .

Think about the logical names of things, and your URLs will be much more resilient to change. That being said, the criticism remains. Machine names change, data gets moved between servers, collections and data sources are merged. Unpredictable (but not unexpected) forces can make your URLs more brittle than they need to be. To deal with this, organizations like the Online Computer Library Center (OCLC) have advocated URL curation services for 15 years. It runs the site http://purl.org to introduce the notion of deliberate URL curation into the mix. PURL stands for Persistent URL. You can define URIs within domains that are resolvable to a PURL resolution server. There is a level of indirection to find where a resource is currently located. It is like the Domain Name Service (DNS) for terms and concepts. Figure 4 shows a concept PURL being referenced and redirected to its current location..

Figure 4. A Concept URL being referenced and redirected to its current location (Click to enlarge.)

Should a resource's location change, its PURL definition can be updated. Clients should remain unaffected.

While the OCLC offers the PURL service for free, you may not want to have a dependency on an external site. Fortunately, the software is available (and was recently rewritten to use NetKernel as its engine!) for download, so you can run your own local versions. (See the article Resources for a download link.)

In conclusion

Resource-oriented architectures provide the flexibility of the Web, scalable implementations, cachable partial results, architectural migration strategies, and increased security profiles. The move to REST is not a move away from SOAP per se, but an embracing of the Web in its entirety. It is no longer acceptable or amusing that it is easier for people to find content on the Web than in their own organizations' systems. It is no longer acceptable that data needs software to be written (over and over again) to convert from one form to another. Being able to register services that do this and find them dynamically should allow you to build highly flexible systems that find information in one form and find ways to convert it to alternate representations on demand.

In an information-driven environment, entirely new business capabilities will emerge while the cost of data integration will plummet. New forms of business intelligence, data mining, data reuse, and collaborative knowledge sharing will emerge.

REST is not the only valid form of integration: SOAP has its place for distributed transactions among asynchronously linked process partners. Messaging is also making a comeback with emerging trends like AMQP and XMPP. These are all valid architectural forms that deserve to be highlighted in their own right. But REST has a special place by virtue of its relationship with the Web. You will be well-served by knowing what it has to offer, and its limitations, as you look to build next-generation systems.

About the author

Brian Sletten is a Senior Platform Engineer at Riot Games, an independent Los Angeles-based game developer and publisher. He has a background as a system architect, developer, mentor, and trainer, with experience in the online game, defense, finance, and commercial domains. Brian has a B.S. in computer science from the College of William and Mary and is in the process of moving to Los Angeles, California.

Read more about Enterprise Java in JavaWorld's Enterprise Java section.