Ajax and REST, Part 2

arcanainjuredΛογισμικό & κατασκευή λογ/κού

2 Ιουλ 2012 (πριν από 6 χρόνια και 20 μέρες)

696 εμφανίσεις

© Copyright IBM Corporation 2006
Ajax and REST, Part 2
Ajax and REST, Part 2
Meeting the challenges of Ajax software development
Bill Higgins
Skill Level: Intermediate
Date: 14 Nov 2006
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.
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
Ajax and REST, Part 2
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
Ajax and REST, Part 2
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.

. 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
Ajax and REST, Part 2
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
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
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
Ajax and REST, Part 2
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
(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
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
Ajax and REST, Part 2
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
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
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
(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
Ajax and REST, Part 2
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
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
Ajax and REST, Part 2
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
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
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
Ajax and REST, Part 2
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.
Ajax and REST, Part 2
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
Ajax and REST, Part 2

Ajax and REST, Part 1
" (Bill Higgins, developerWorks, October 2006): Learn
the advantages of the Ajax/REST architectural style for immersive Web

Debug JavaScript in Internet Explorer
": A how-to on the Microsoft Script Editor,
which ships as an add-on to Microsoft Office.

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

Read the
author's blog

Ajax resource center
: Your destination for everything Ajax on developerWorks.
Get products and technologies

Dojo Toolkit
: Dojo is an open source Ajax framework with libraries to help with
module management, event handling, and remote communication. Dojo's
packaging system that lets you easily build and deploy a custom version of your
Ajax code and only the parts of Dojo that you need.

: Aptana is an open source JavaScript-focused IDE with versions for
multiple platforms.

Eclipse Ajax Toolkit Framework
(ATF): ATF provides an integrated Ajax toolkit
including a DOM inspector, XHR monitor, and "view live source" functionality.

: FireBug integrates with Firefox to provide an error console, DOM
inspector, and XHR monitor. It includes "view live source" functionality.

Venkman Debugger
: A JavaScript debugger for Firefox.

Internet Explorer Developer Toolbar
: DOM inspector and other tools for IE.

: XHR monitors for Firefox/Mozilla.

HTTP Analyzer
: XHR monitors for Internet Explorer.

Ajax discussion forum
: For questions regarding Ajax development, this forum,
moderated by Jack Herrington, can help you get started.
Ajax and REST, Part 2
About the author
Bill Higgins
Bill 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
developerWorks blog
, reading, and playing basketball.
© Copyright IBM Corporation 2006