The Easiest Way to Get Started with Ajax and REST

Problem You want to know the best way to get started with writing Ajax and REST. Solution When developing an Ajax and REST application, you must decide on the tools and frameworks you’ll use. The choice is simple: Use whatever you’re using today, and write some Ajax applications. You don’t need to change the tools you’re using today. Whether you’re using ASP.NET, JavaServer Pages (JSP), PHP, Ruby, or Python, you can continue with those tools. Ajax uses JavaScript, DHTML, and the XMLHttpRequest object, but ASP.NET, PHP, and similar technologies don’t hinder you from writing HTML pages that make use of Ajax techniques. If your technology does hinder you from writing Ajax applications, then you should think hard about continuing using the technology.

After all, you’re reading an Ajax and REST recipe article, so I assume that you plan on implementing Ajax and REST solutions. When decoupling the client from the server, you can create the content on either side independently. You can develop the client using technologies such as DHTML and JavaScript. Within the client, you can code references to services offered by the client. The client-side code provides an infrastructure where the content generated by the services can be injected. The client and server interact with each other using contracts. Using contracts, you can develop the client independently and test it using mock objects. Using contracts, you can develop the server independently and test it using tests from a test suite. Then when the client is combined with the server, the application will work without requiring a large amount of further testing. Of course, this assumes that the tests for the client and server are implemented properly normal testing is often also required. Having decoupled the client from the server, you can easily modularize and delegate the

implementation work to individual team members. Allowing each team member to focus on the task makes it possible to specialize and create innovative content. For example, delegating the database work to the server allows a client developer to make more use of graphics and innovative representations of the data generated by the service. Delegating the UI work from the server to the client side makes it possible for the server developer to focus on database optimization and access speeds. Having decoupled the client from the server, you can make use of specific frameworks to make it simpler to implement specific pieces of logic. For example, a client-side developer could use the Prototype8 or Dojo9 frameworks. Which toolkit you end up using is your choice, and there is no right or wrong answer. You need to investigate what you need and see if the framework offers that functionality. When getting started with Ajax and REST, remember the following points:

• You can use Ajax and REST today with existing technologies. You generally don’t need to throw out old technologies and replace them with new ones.

• Ajax and REST are about decoupling the client from the server and making using of Web services.

• Ajax and REST frameworks can make it simpler for you to implement your applications, but because there are so many frameworks, you need to inspect them to see if they fulfill your needs.

Implementing an Ajax and REST Application Using Test-Driven Development Techniques After you’re convinced that you want to develop Ajax and REST applications, you’ll want to execute some testing routines. Problem You want to know the best way to test your Ajax and REST applications. Solution This recipe explains the different layers of test-driven development techniques.10 There are different layers because an Ajax and REST application involves both client-side and server-side code. To put it simply, you don’t hire a few users to test an Ajax and REST application and get them to try out application scenarios. As stated earlier, the server side and client side are decoupled from each other.

This is a good approach for testing purposes, because you can develop and test the client and server independently of each other. An architect has the ability to define a contract between the client and server, enabling each to work independently of each other. URLs. The four layers range in implementation complexity from complicated to straightforward. Each layer, which is explained as follows, is associated with a numeric identifier:

• GUI-level tests involve testing the Ajax and DHTML user interface.

• REST-level tests test the REST and Web service interfaces for correct implementation of the defined contracts.

• Server-side class-level tests test the implementation of the functionality using test-driven development techniques.

• Mock URL-level tests are not actually tests, but rather implement the contracts defined by the REST and Web service interfaces. The mock implementations allow you to test the GUI without needing a completed server-side implementation. Each layer requires using a different testing toolkit, as each layer tests a different aspect of the Ajax and REST application. However, this raises a question: Do you start developing with the server side or the client side? Do you develop using top-down techniques or bottom-up techniques? You could develop all the layers at once using agile techniques, though it’s not a good idea. The problem is that by using agile techniques on all of the layers at once, you instantly create a communications overhead and defeat the purpose of decoupling the client from the server. In a complete agile manner, the client, contract, and server are all developed at once. If the client has a problem, that might cause a change in the contract and the server, causing the client and server to become coupled. It is not to say that you shouldn’t develop using agile techniques. What you need to do is direct the agile techniques so that the client and server are decoupled from each other. Thus, the first thing you should develop are the contracts that the client uses and the server provides. The idea behind this architecture is to test and implement a complete user case without actually implementing the client or server. The testing layer 2 represents a set of tests used to verify that the server-side implementation is complete.

The Mock URL layer represents a set of tests used to verify that the client-side implementation is complete. By having the testing layer 2 verify the data generated by the Mock URL layer, the contracts for completeness are verified. Practically speaking, you could use a programming language such as Java to make a series of Web service calls that define a contract. These Web service calls represent scenarios that the client implementation would execute. You would implement the scenarios using agile techniques defined by application use cases. For example, if a use case is to open a bank account, then you would create a test that would make the appropriate Web service calls to open a bank account. A test cannot function without some implementation. And since you don’t have an implementation, you must fake the request and response or, more appropriately, use the Mock URL framework. The role of the Mock URL framework is to anticipate the client tests. When a test is underway, the Mock URL framework verifies the data sent by the test and then generates the appropriate response. The verification and generation are the result of performing some logic and loading and sending pregenerated application data. It is important that the Mock URL not implement business logic, but rather use canned logic and pregenerated requests and responses as much as possible. When the contracts are implemented properly, the tests should not be able to tell if a live implementation is generating the data or if some layer has faked the data.

Appropriately, the Mock URL framework should not be able to tell if it is being called by a series of tests or if it is live client implementation. The combination of tests and Mock URLs allows you to use agile and test-driven techniques to create the contracts that the client and server need to implement. If you feel that creating a complete mock layer is too much work, then you could create an implementation that has canned returned values. Having defined the contract, the implementations of the client and server know what they need to do. In order for you to use agile techniques to implement the client and server, the tests have to be a finer granularity than the contracts. The implementation tests need to be extensive and go beyond the contract and may include other aspects such as data initialization and presentation. For example, the test layers 1 and 3, are not related directly to the contracts and are used to test the client- and server-side implementations. Starting with layer 3, you use the tests to test the functionality of the implemented serverside logic.

From a programmatic perspective, this means that a clear separation exists between the implemented logic and the technology used to present that logic using the HTTP protocol. The test layer 3 doesn’t depend on or care about how the logic is exposed to the HTTP protocol. The tests in layer 3 focus on making sure that the server-side logic is implemented correctly. The contracts that the tests verify are not exposed externally, and the client doesn’t care what the tests are. Because the tests are private, the server developer can define their class structure, using whatever technology desired without affecting the client. Testing the server requires using the correct test framework; a few of these frameworks are outlined as follows:

• JUnit (http://www.junit.org): Java test-driven development framework. JUnit is the original unit-testing tool.