The REST of the Story

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Skip Sauls' Blog | July 5, 2007  12:27 PM | Comments (2)

Mashups - Where's the Beef?

I'm a big fan of most things Web 2.0, and I believe that the concepts and technologies that are now emerging will play a big role in how we build applications long after the buzz has faded. Mashups and "situational apps" are great concepts, but at the present far too many examples are technical showcases without a lot of substance. A business user isn't as likely to be impressed with how many different ways a map can be mashed up with addresses that aren't relevant to their job. Nor will they think that the latest AI-assisted context-sensitive fish-eye list is interesting if they can't use it with their corporate data. Much of the current crop of mashups may end up as orphans because no one will find them interesting enough.

So what do we do to ensure that the applications we create are truly useful? Well, if you're using BEA WebLogic and AquaLogic products for SOA, web applications, and enterprise computing, you've already solved many of the hard problems. You have ways to get to the processes, data, content, and services that the business users need to do their jobs, and it's likely that you have existing Web 1.0 applications in place. But what about Web 2.0, and how are you going to get there? There are lots of possibilities, and it's going to be confusing for a while, but I have one thing to suggest that you keep in mind until all of the dust settles: REST.

Representational State Transfer (REST)

There are many great articles, discussion, blogs, and so on about REST, so I'm not going to make this a tutorial on the subject. This series will make more sense if you understand the principals of REST, and I'd like to suggest the following:

Representational State Transfer - Wikipedia
RESTful Web Services by Leonard Richardson, Sam Ruby
Representational State Transfer (REST) - Chapter 5 of Roy T. Fielding's Dissertation

The Miracle

A colleague of mine came up with a great description of how the gap between the enterprise and Web 2.0: "Then a miracle occurred." If you've built Web 1.0 applications then you probably used technologies such as JSP, JSF, Struts, Beehive, and more to provide the user interface to enterprise applications. These work well if you know J2EE, and are well suited for the traditional request-response architecture. With the rise in demand for Web 2.0 features, you have to figure out how you're going to add these features without having to throw everything out and start over.

Despite the title of this section I'm not here to suggest that REST is itself the miracle that will bring Web 2.0 to the enterprise. What I believe is that it can be an essential part of the solution when combined with RIA (Rich Internet Application) technologies such as Ajax, Flex, Silverlight, and more. The RIA toolkits and products help make applications more usable; REST will help ensure that the applications are truly useful. By using REST you can unlock the enterprise data for use in Web 2.0 applications without giving up the various "ilities" that are expected.

A Quick Demonstration

If you've read up on REST or have played with it already, you'll know that one of the basic features is HTTP accessibility. There are a number of prototype REST services deployed on wlp.bea.com, and I'll be revealing more of them in subsequent entries, along with lots of sample code. To see REST in action now, simply open a web browser and enter the following URL:

http://wlp.bea.com/rest-web-lib/api/content.nodelist?repositoryName=BEA%20Repository

This will return an XML document that looks something like the following snippet:

<?xml version="1.0" encoding="utf-8" ?> 
<rsp stat="ok">
  <name>null</name>
  <nodePath>null</nodePath>
  <id>null</id>
  <type>null</type>
  <nodes>
    <name>Demo</name>
    <path>/BEA Repository/Demo</path>
    <id>/BEA Repository/2001</id>
    <type>folder</type>
    <workflowStatus>published</workflowStatus>
  </nodes>
  ...
<rsp>

These nodes represent the top level of the specified repository, and each folder type may be browsed by appending its path to a nodePath parameter on the URL. For example, you can see what's under the Demo folder with the following:

http://wlp.bea.com/rest-web-lib/api/content.nodelist?repositoryName=BEA%20Repository&nodePath=Demo

If you follow the folder hierarchy to Demos/Images/Logos, you'll see a list of images such as:

<?xml version="1.0" encoding="utf-8" ?> 
<rsp stat="ok">
  <name>Logos</name>
  <nodePath>/BEA Repository/Demo/Images/Logos</nodePath>
  <id>/BEA Repository/2009</id>
  <type>folder</type>
  <nodes>
    <name>BEA</name>
    <path>/BEA Repository/Demo/Images/Logos/BEA</path>
    <id>/BEA Repository/2010</id>
    <type>image</type>
    <workflowStatus>published</workflowStatus>
  </nodes>
  ...
<rsp>

So how do get the details of an image? Use the content.node command with the path as follows:

http://wlp.bea.com/rest-web-lib/api/content.node?nodePath=/BEA%20Repository/Demo/Images/Logos/BEA

This will return the XML describing this node, with properties that match those for the specific content type. This prototype service treats images as a special case, returning the URL for displaying the image with the ShowProperty servlets rather than the binary data. To display the image the following URL can be used:

http://wlp.bea.com/rest-web-lib/ShowProperty?nodeId=/BEA%20Repository/2010

Here's the image:

Using the Data in a Client Application - JSON to the Rescue

XML is a great way to represent data, but it doesn't always lend itself for use in a client, especially one that is JavaScript-centric. Thankfully we have JSON (JavaScript Object Notation) which is inherently JavaScript friendly, and is often used with REST. We can get the JSON response for any REST request by using the format=json parameter, as in the following:

http://wlp.bea.com/rest-web-lib/api/content.node?nodePath=/BEA%20Repository/Demo/Images/Logos/BEA&format=json

An interesting point is that while JSON is easier to use with JavaScript, it can be harder to read than XML. Try the URL above and view the response in a text editor. You may find that Firefox does a better job with this than IE. The good news is that the point of JSON isn't readability by humans; rather it's how easy it is to use the data in JavaScript. A JSON response can be turned into a JavaScript object with code such as the following, where the responseText from an XMLHttpRequest is evaluated:

var result = eval('(' + xhmlHttpReq.responseText + ')');

The result object can be used with standard dot notation, allowing for example "result.content.name" to get the node name, "result.content.properties" to get the array of properties, and so on. This works nicely with many JavaScript libraries and applications, which I'll be describing and demonstrating in subsequent blog entries. Source code for JavaScript libaries, including some based on Dojo, will be provided. I'll also demonstrate how to use these REST commands with various types of mashup tools and technologies.

Stay tuned!

Comments

• This is interesting Skip. I wonder about your URL naming scheme. Your URL looks like this:

  http://wlp.bea.com/rest-web-lib/api/content.nodelist?repositoryName=BEA%20Repository&nodePath=Demo

  I would have expected something like this:

  http://wlp.bea.com/rest-web-lib/api/nodes/BEA%20Repository/Demo

  for example. Does your URL naming schemes really reflect the data - I guess I'm struggling to find the border between true ROA (REST Oriented Architecture) and the more 'traditional' architecture. I guess what will make it easier is if I knew exactly was exposed - what are the resources that are being made available and the operations on those resources?

  Hey, BTW, in Java land someone recently pointed me to Restlet for adding REST-like functionality to an app - looks interesting...

  Posted by: jonmountjoy on July 7, 2007 at 8:57 AM

• Hi John, thanks for the feedback. I'm using an early prototype REST framework for WLP and the naming/URL scheme could still change. We've been researching this and hope to come up with one that will satisfy most folks, or ideally one that is "pluggable". The commands themselves shouldn't care what the format of the URL is, and if/when things change it would be nice to be able to easily adapt. I'll cover more about what's being exposed in upcoming blog entries. These prototypes are being used to demonstrate more of what is possible rather than how the actual implementations will eventually work, and look. I haven't looked too closely at Restlets, but I believe some folks here may have done so. At a glance it looks interesting, and I've seen some other articles and frameworks that may also prove to be.

  Posted by: skip on July 9, 2007 at 1:31 PM