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

The REST architectural style in the Semantic Web

From an IT manager's perspective, REST might just be another way of moving information, but without all the tools associated with SOAP. In this final article in the REST for Java developers series, Brian Sletten takes on that myth, and several others about REST, by looking at its role in emerging architectures such as the Semantic Web. The move to REST, he says, is not a move away from SOAP, but an embracing of the Web in its entirety, both inside and outside of the enterprise. Level: Intermediate

So far in the REST for Java developers series you've learned hands-on about the RESTful way of doing things. If you're reading this article it's safe to assume you're interested, even excited, about applying REST in your Java-based development. But what about other developers and managers in your shop? If you want to start building RESTful interfaces at work, you need to be able to explain why REST is the basis of future information systems, and why it's worth adopting now.

In this last article in the series, I discuss REST concepts as the foundation for dynamic, scalable, resource-oriented architectures. I'll demonstrates how REST's goals and vision align with larger plans for the Web itself. I'll also explain how concepts like HATEOS, resource description and discovery, and linked data are already at work in projects such as the Linking Open Data project and how they apply to enterprise data integration. Finally, I'll discuss how this overall approach can strengthen your security profile, and leave you with some ideas for improving the longevity of your RESTful interfaces.

Information resources

As you know from the first article in this series, Roy Fielding defined REST to describe the properties that emerge from the deliberate application of certain architectural constraints. The REST architectural style is built on the idea of a layered, stateless client-server interaction. RESTful interactions occur through uniform interfaces with support for caching and optional extension by code-on-demand, as shown in Figure 1.

Figure 1. REST's constraints combine to provide a flexible, scalable architecture. (Click to enlarge.)

As a further reminder of what REST is, here's what it is not:

  • A means for invoking arbitrary behavior through URLs
  • A drop-in replacement for SOAP
  • Easy
  • A toy

REST, then, gives you a relatively simple means of interacting with arbitrary addressable resources. Those resources can signify your business data, concepts, back-end services, and policies -- anything, really. The logical connection gives you the ability to pass around references rather than data, allowing heterogeneous systems, applications, and users to consume the data differently when and where they need to. Late-binding content negotiation is a powerful concept that you see in any real RESTful system.

An environment like NetKernel takes late-binding content negotiation a step further with the idea of an executable infrastructure to support the transformation of resources. Recall that NetKernel serves up information resources in various flavors called aspects. One of its most useful concepts is the ability to convert between these forms declaratively. You have an XML document as a DOM aspect, but what if you want it as a node set to send off for XQuery processing? NetKernel will do this on the fly via a process called transreption (transforming representation).

This notion, applicable to REST systems in general, frees you from the need to spend years defining common schemas that are always out-of-date and that suffer from what I call the Tyranny of the Common Form. The social costs of getting everyone to agree to the definition of these central models always outweigh the technical costs of implementing them. The process of normalizing to a common form often forces modelers to drop edge-case information. So, not only are these efforts expensive, but they are also often unsuccessful and sometimes even lossy.

Being able to convert data from an XML representation to a rendered representation may seem like magic, but it's not. You experience this every day on the Web. The trick is to take the next step and think about your information more generally. The fact that the same interaction style gives you late-binding, content-negotiated freedom to build flexible systems that scale and can be migrated without breaking clients is icing on the cake. REST is not of interest because it is simpler and easier than SOAP: REST is of interest because it solves real business and technical problems that have plagued the IT industry for years.

1 2 3 4 5 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more