Ajax and REST, Part 2

Meeting the challenges of Ajax software development

Ajax has begun to explode in popularity. Old Web frameworks are retrofitting themselves to support Ajax, new pure-Ajax frameworks are under development, and many organizations are considering Ajax adoption or are already building Ajax applications. But for all the excitement, relatively few organizations have deployed Ajax applications successfully. This article, the second in a two-part series, will help you decide if you should use Ajax in real IT applications, and it aims to improve your chances of success with Ajax development.


Bill Higgins (bhiggins@us.ibm.com), Rational, IBM

Bill HigginsBill Higgins works for the IBM Rational Software division, where he works on tools to support development teams. Bill graduated from Penn State University in 2000 with a B.S. in computer science. Outside of work, Bill enjoys spending time with his wife and two children, posting to his developerWorks blog, reading, and playing basketball.

14 November 2006

Also available in Chinese Japanese

In Part 1 of this two-article series, I discussed the potential benefits of an Ajax/REST architectural style for Web applications that require dynamic and personalized user interfaces but must also scale. Given those requirements, I explain why the Ajax/REST architectural style is superior to traditional server-side Web application architectural style in terms of its run-time characteristics. But your users can enjoy these positive run-time characteristics only after you've successfully envisioned, planned, developed, tested, and deployed your Ajax application. This article addresses development-time characteristics of Ajax/REST applications. It aims to help readers who are interested in using Ajax in real applications to answer two important questions:

  • Should you use Ajax technology in your IT applications?
  • If so, how can you improve your chances of successfully developing and deploying Ajax technology?

The newness of the Ajax/REST architectural style presents challenges to organizations that have traditionally used the server-side Web application style. Though Ajax has several compelling architectural advantages over the traditional model, an immediate and total transition to a pure Ajax/REST architecture isn't realistic for all organizations. Those that lack Ajax development skills can begin their Ajax exploration by incrementally adding Ajax functionality to existing server-side Web architectures. As these organizations begin to gain experience with Ajax/REST, they can confidently attempt more interesting and ambitious projects.

Check out the Ajax Resource Center, your one-stop shop for information on the Ajax programming model, including articles and tutorials, discussion forums, blogs, wikis, events, and news. If it's happening, it's covered here.

Should you use Ajax?

Ajax is an architectural style composed of a set of technologies. Technologies are not good or bad in and of themselves; they are neutral. A technology is more or less useful only insofar as an organization can apply it to solve a particular problem or to fulfill a particular need. So to answer the "Should I use Ajax?" question, you must evaluate what your organization is trying to achieve, how Ajax can help (or not help) you achieve it, and whether your organization has the right people to succeed.

Consider the spectrum of adoption options

You may be wondering what it means to "adopt Ajax." To take advantage of Ajax, an organization need not rewrite an application using a pure Ajax/REST architecture. I recommend that you start small and get your feet wet to gain experience and confidence rather than diving directly into a pure Ajax/REST architecture.

Adopting Ajax can mean doing something lightweight and subtle -- perhaps reimplementing a minor feature of your Web application to be cooler and more responsive. This lightweight style is exemplified by the Netflix movie feedback feature. Customers can quickly score movies by clicking on between one and five stars. Each click immediately updates their Netflix preferences and adjusts recommendations accordingly.

At the high end of the adoption spectrum are applications such as Google's Gmail and Maps, which have redefined the state-of-the-art in Web application development. These applications are notable for their many intuitive interactive features, visual pizzazz, and ability to adjust their user interfaces constantly based on user actions and user data.

It's certainly fun to imagine the positive response you'd get if you released something as sophisticated as Google Maps for your industry. But be realistic. Google has perhaps the best Web development organization in the world, so it's dangerous to use it as a benchmark of what's possible with Ajax. And don't forget that Google (wisely) doesn't announce new applications until they're ready for prime time, so we only see the successes. I would speculate that even the brainiacs at Google have occasionally failed with Ajax and we simply never learn about those failures.

Pure Ajax/REST is a young architectural style that's still difficult to implement compared to more-established Web application styles such as JavaServer™ Pages technology (JSP) and PHP. Unless providing a next-generation Web user experience is a primary requirement and you have world-class Web development team, your organization will fare better by initially adopting "Ajax in the small" like Netflix rather than "Ajax in the large" like Google.

Assess how Ajax can help you achieve your goals

Ask yourself what characteristics of the Ajax programming style make it attractive to your applications' needs. Does your company seek productivity gains that a more responsive UI could provide? Do you want to deploy an application that's both highly dynamic and personalized, yet still scales? Is "coolness" a differentiating feature for customers in the market segment that you target? Any of these are valid reasons, and there are others. The point is that you must be able to articulate a compelling reason to adopt Ajax. Here are three things Ajax does well:

  • More-responsive UIs. In a traditional server-side Web application, any interaction with the server requires a page refresh, meaning a two- to five-second delay and a jarring full redraw of the page. Ajax lets the user interact with the server via a "fire and forget" interaction style: the user performs an action and the system can process it in the background while the user continues with other work. And the UI only needs to update regions that have new information to display, rather than always redrawing the entire page. If done well, an Ajax-style UI can let the user achieve and maintain flow, improving both user satisfaction and productivity.
  • Sexiness. For externally facing applications and products, it's no longer enough just to have a good product that does what it needs to do. Too many options are out there for your customers. You need a product that will gain attention and captivate users. As the saying goes, "sexy is a feature." This doesn't mean you include every bell and whistle your developers can imagine -- look at how the iPod with its minimalist design has blown away other portable music players with 10 times the number of controls. The key is to provide an elegant design filled with subtle features that help users do what they need to do in a pleasant, enjoyable way.

    Gmail is a good example. On the surface, Gmail's just another Web-based e-mail application, and those have existed for 10 years. But Gmail gets the little things right using Ajax. Ever lost a long, unsent e-mail message because you accidentally closed your browser? The Gmail developers considered this and unobtrusively save a copy of your unsent message to the draft folder every minute or so. Ever found it annoying to look up an e-mail address that you use all of the time? The Gmail developers considered this and provide an unobtrusive address-completion mechanism based on past e-mail messages you've sent.

    Sexiness is often important for external and commercial applications, but it's much less important for internal business applications. It's all about context.

  • Personalization without sacrificing scalability. As traditional server-side Web applications have grown more dynamic and personalized over the past 15 years, developers and middleware have increasingly tended to store a lot of session state on the server side. This approach enables personalization but hampers scalability. As you learned in Part 1, Ajax applications tend to store session state on the client side and interact with the server via stateless services, allowing highly dynamic and personalized Web applications without sacrificing scalability.

Make the call

Would any of these three benefits help your organization succeed? If not, does Ajax provide some other unique advantage that could contribute to your organization's success? If you don't have a compelling, concrete reason for exploring Ajax, I suggest you drop it until you find one. If you do have a compelling reason, read on.

Succeeding with Ajax

So you've decided that Ajax could provide some unique value to your organization that justifies the increased risk that it brings along as an emerging technology. This section discusses how to incorporate the Ajax technologies and techniques into your application and software development process successfully. I'll deal with some special considerations for developing "Ajax in the large" in the next section.

Start small, gain experience, build confidence

Nothing sinks a useful emerging technology faster than a project that attempts to use it and fails spectacularly. This is usually the result of trying too much too soon with inadequate skills. But it's difficult now to find developers with nontrivial Ajax development experience; the technology is simply too new.

To deal with this problem, development organizations should look to gain experience with Ajax by implementing it on real projects, but on noncritical features. Focus on quickly getting something small deployed into the real world. Learn from your mistakes and adjust. If you try to go too big too soon, you introduce a great deal of risk to your project. And the bigger you go, the longer it will take to go through a full design/develop/test/ deploy cycle, which is the key for gaining real, practical experience.

This advice applies more to organizations attempting "Ajax in the small," but with "Ajax in the large," you can still start small by developing in an iterative manner, as I discuss in Special considerations for "Ajax in the large."

Find the right people for the UI and for the services

It's tempting to think that your team of Web developers who have successfully delivered PHP, Java, or .NET server-side Web applications over the past 10 years will seamlessly transition into expert Ajax developers, but this is unlikely. Although you're still playing in the Web development space, both the Ajax architectural style and supporting technologies require developers to unlearn old assumptions and to learn new idioms and patterns. Making the transition is possible, but it takes time.

In traditional server-side Web development you process link clicks and form submissions, and respond with a full HTML page. Often a workflow spans a number of pages, so your server-side application logic must maintain a conversation with the browser. The server must remember the entire application state from click to click so it can provide an apparently seamless workflow as the user interacts with the Web application. In an Ajax world you move away from this "green screen" model to a true client-server model, where the client is stateful and dynamic, and where the server is responsible only for providing atomic, stateless services. This new programming style requires different types of skills on both the client and server sides.

On the client side, you'll need people who are strong in CSS, JavaScript, and Document Object Model (DOM) programming. The problem is that most development organizations say "we have experience with JavaScript and CSS," but this usually refers to trivial functions such as decorating text and client-side form validation. Thinking that a server-side Web developer with this trivial JavaScript/CSS experience is qualified to work on a large-scale Ajax application is like thinking that someone who knows how to drive a car is qualified to race in the Daytona 500.

This is yet another reason why it's important to start small. Your Web developers might not have the level of skill and experience to create a Gmail-caliber Ajax application now, but they should be able to deliver something small and real on top of an existing server-side Web application. With time and experience they'll gradually be able to implement more-sophisticated scenarios using Ajax.

On the server side, Ajax presents a shift because you can get out of the unattractive business of managing session and workflow state on the server. The Ajax style of "stateful client / stateless server" is much simpler to understand and manage once you gain experience with it, but this change in architectural style requires new skills. Your service developers should have a strong understanding of the HTTP protocol, knowledge of the REST architectural style, and experience developing distributed services such as remote method invocation (RMI) and remote procedure calls (RPC). Though the REST architectural style has some basic differences from RPC, some of the nonfunctional principles involved (security at the borders, network latency, and nonreliability) carry over.

Use a framework

The DOM, CSS, and XMLHttpRequest (XHR) "standards" vary significantly from browser. Developers who don't choose a preexisting framework to sort out these differences will spend many unplanned cycles writing their own plumbing code to normalize the cross-browser inconsistencies. And it will be a long time before your plumbing code reaches the level of quality that frameworks available today have already achieved. One promising framework is the open source Dojo toolkit (see Resources).

Learn and use tools

Developing Ajax applications involves two distinct activities: implementing the UI and application logic using HTML/JavaScript/CSS/DOM, and implementing service logic using established server-side platforms such as PHP, J2EE, and .NET. On the server side, you can use the same tools you've been using. On the client side, you'll need to find learn how to use some new tools. You'll likely need a different Ajax toolset for each browser you wish to support. Here's a list of general tool functions (see Resources for links to some tools that support the two most popular Web browsers, Microsoft Internet Explorer and Mozilla Firefox):

A pain point

A common pain point for developers coming from a J2EE or .NET background is the immature state of code-completion functionality for the JavaScript programming language. This is a result of JavaScript's dynamic typing, and of the fact that JavaScript's historically small user base didn't create a marketplace for great code-completion technology. Code completion is improving with tools like Aptana, but it's a long way from what Eclipse Java developers or Visual Studio C# developers have grown accustomed to.

  • Writing code: Editors and IDEs. In client-side Ajax development you write a combination of HTML, CSS, and JavaScript files. Code editors improve your productivity by providing syntax highlighting, syntax error detection, and code-completion technologies.
  • Inspecting structure: DOM inspectors. Because much of the visual structure of an Ajax Web page is created dynamically as the user interacts with the page, it's not enough simply to view source in order to explore the page's live structure. The source likely won't even loosely resemble the UI you're viewing. You need to inspect the DOM structure as you interact with the page. A nice complementary feature to a DOM inspector is a "live source" viewer that reverse-engineers what HTML source code would look like for the current state of the DOM, giving developers accustomed to viewing HTML source an intuitive way to think about page contents.
  • Inspecting behavior: JavaScript debuggers. When writing small JavaScript scripts to validate forms or provide minor interactivity, most developers can troubleshoot problems with simple alert statements. But when you make the jump to larger-scale Ajax development, you need to find and learn a JavaScript debugger for each Web browser you intend to support.
  • Inspecting client-server interaction: XHR monitors. A final important tool for your Ajax toolbox is an XmlHttpRequest (XHR) monitor. XHR is the JavaScript object that enables the Ajax-style remote communication with the server. An XHR monitor lets you monitor the request/response pairs, including their headers and contents.

Test in a realistic environment

What about unit testing?

With tooling and agile methodologies being in the forefront of today's development landscape, you may be wondering where unit testing fits into the Ajax picture. As of this writing, there's no dominant unit testing framework for Ajax. Rather, each framework (such as Dojo or Scriptaculous) tends to have its own optimized unit testing framework. Chapter 19 of Michael Mahemoff's Ajax Design Patterns (see Resources) provides a nice summary of the state of unit testing circa 2006 and discusses unit testing functionality for the various Ajax frameworks.

It's been well documented that without extra effort on the developer's part, Ajax breaks some of our basic expectations of a Web site: for example, the Back button, bookmarking, or the browser's "loading" control might not work. My "start small" advice will help you here as well. As long as you use Ajax only to implement incremental new features that update a page's state but don't affect navigation or workflow, the Back button and bookmarking are nonissues. But the loading time can be an issue, especially if you test only on your local development environment, where network latency isn't much of a factor.

Consider this: In a traditional Web application, when users click on a link or submit a form, even if the subsequent page load takes 10 seconds, they see immediate feedback from the browser's "loading" control. In an Ajax application, clicking on a control that triggers an XHR request doesn't activate the "loading" control. The danger of testing only on a local development environment is that the HTTP request, response, and subsequent UI update appear to happen instantaneously, making the lack of browser "loading" feedback seem to be a nonissue. But in a production environment where the user might be hundreds or thousands of miles away from the server, this lack of feedback can be confusing and frustrating. The user wonders: "Did I click on that control? Let me click it again. Still nothing!"

Unfortunately, despite your best engineering efforts, network latency will still exist, so you must accept it. Assume some time lag between user click and the arrival of the server's response. When a user performs a gesture that initiates a remote call, provide immediate feedback that you've received the gesture. Temporarily disable the control or display a message that something's happening, and don't remove the message until you've received the server response and have something to update the UI with. The network call is the bottleneck; it's hard to write JavaScript code that takes a noticeably long time to execute.

The key point is to test in a realistic environment, where these usability problems will be easily noticeable. The earlier you catch them, the earlier you can respond appropriately.

Another aspect of testing in a realistic environment is to ensure that you execute each functional test on each browser type and version that you support. For example, if you claim to support Firefox 1.5 and 2.0 and Internet Explorer 6 and 7, then you need to test constantly on all of those browsers. This may seem obvious, but it's easy for developers to fall into the bad habit of developing and testing only on their favorite browser and later needing to rework code as problems are found on other browsers.

Special considerations for "Ajax in the large"

Although I've recommended that you don't try to create an Ajax application as ambitious as Gmail or Google Maps, business factors or engineering bravado might compel you to try. My first reaction is: don't do it -- start small and gain experience. But if you're intent on building a big pure-Ajax application right now, read on.

It's all about your people

Your development team is even more important now, because you're not simply extending a proven architecture with new technology, but you are embarking on a new architecture. Your team will need to make major design decisions with little Ajax experience -- design decisions that could go horribly wrong.

You'll need people who have deep experience with JavaScript/DOM and CSS. If you don't have anyone with deep JavaScript experience, then look for developers with deep experience in another scripting language like Perl, Python, or Ruby. Experience in a functional programming language like Lisp or Scheme is a big plus, but experienced Lisp/Scheme programmers are rarer than experienced JavaScript programmers..

Don't underestimate the importance of good CSS on your application's quality. The lack of someone with deep CSS understanding can lead to unnecessarily awkward and unmaintainable code, which will make your first and second rewrites much more difficult.

Rewrites, did you say?

Plan on rewriting it ... at least twice

Whenever you're working on greenfield development, the chances of getting the major design decisions correct the first time are low. You can either lumber on with a brittle and flawed design, or you can do the agile thing and constantly refactor your design as you gain knowledge and experience of what works and what doesn't.

Ajax presents unique challenges because both the user experience and the underlying architectural patterns are deceptively different from their server-side counterparts. You'll probably find subtle but persistent flaws with your UI: the Back button doesn't work as users expect, there's not much feedback when the user invokes a remote action, and so on. Unfortunately, it's hard to design solutions for these problems until you've experienced them and understand how your design must change to fix them.

Another reason you'll want to rewrite your application is that as you gain experience with JavaScript/DOM and CSS, you'll discover new idioms and patterns that lead to much more concise, readable, and maintainable code. Also, as you write more code, you'll start to factor out common behavior that's not quite generic enough to be in your third-party framework but is common enough that it belongs in your own library rather than sprinkled around top-level code. Refactoring old code to use new library code will pay off in the long run, but it takes time and persistence. You also may find yourself gradually moving into the framework business, which has its own sets of problems.

Beware of entering the framework business

As you make progress on your large-scale application, you'll observe that many general-purpose application services aren't provided by bare-bones JavaScript/DOM/CSS or by emerging Ajax frameworks like Dojo and Prototype. It's tempting to create your own framework-level code to simplify the creation of new application-level functionality. This isn't always a bad thing; most of the best development frameworks (Ruby on Rails, for example) have been extracted from concrete application needs. But beware; I've warned that Ajax in the small is doable, but Ajax in the large is significantly harder -- probably an order of magnitude harder. Designing framework-level technology to support Ajax in the large is yet another order of magnitude harder, especially if you're relatively new to the world of Ajax technology.

Framework code introduces more levels of abstraction and indirection that make code paths harder to understand. A good rule of thumb is to work at the concrete application level as much as possible and only think about moving some code into a framework or reusable library when at least three different parts of your application could use the services provided by the code.

Iterate, iterate, iterate

A major antipattern of greenfield development is that you spend too much time between initial design and having a tangible product that real people can use and provide feedback on. So, on your big ambitious new Ajax application you should try to get something basic working and demo-able within a few weeks to start getting feedback. The UI will be primitive and the code might be ugly, but you'd have the same result if you developed for six months before letting people play with your new application; the only difference is you'd have 10 times as much code and UI to chuck.

Favor quick iterations over long design periods, and constantly let real users experiment with the product in an environment that simulates production conditions. The high end of this approach is to have a test server that you update every several days with new code that your users and project leaders can experiment with and provide feedback on.


The biggest risk of adopting Ajax technology is the general lack of practical experience in the industry. Because of this, I recommend starting small, letting your development team gain experience and confidence without causing major risk to your project. If you decide you want to take the full plunge into pure Ajax at this point, do so with a realistic understanding of your low probability of success. Unless you have a world-class Web development team and the kind of development organization that supports iterative development and experimentation, you'll probably fail.

Over time, though, things will get easier and less risky as more practitioners gain experience and as frameworks, tools, and best practices emerge. Ajax will become safer and more routine... if not nearly as exciting.


I'd like to thank my Rational colleagues Erich Gamma, Grady Booch, Josh Staiger, Pat Mueller, and Scott Rich for sharing their insights and providing feedback on this article.



  • "Ajax and REST, Part 1" (Bill Higgins, developerWorks, October 2006): Learn the advantages of the Ajax/REST architectural style for immersive Web applications.
  • Ajax Design Patterns (Michael Mahemoff, O'Reilly, 2006): Mahemoff's chapter on Ajax testing provides a nice summary of the state of Ajax unit testing circa 2006.
  • Ajax resource center: Your destination for everything Ajax on developerWorks.

Get products and technologies


  • Ajax discussion forum: For questions regarding Ajax development, this forum, moderated by Jack Herrington, can help you get started.


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Web development on developerWorks

Zone=Web development, Java technology
ArticleTitle=Ajax and REST, Part 2