Summary

7.7

ZZZLWHERRNVLQIR

In this chapter you learned best practices that, taken together, make the difference
between a prototype Restlet application and a more mature one suitable for production.
You first saw how to complete an application with the usual web elements manipulated in most web APIs and websites, such as HTML forms handling, static file serving,
and cookie manipulation. Each feature has been carefully illustrated in the context of
the ongoing mail server example.
You also learned two complementary ways to handle web feeds in the Atom and
RSS formats using two Restlet extensions, comparing the advantages and disadvantages of each of them. Then you learned how to redirect client calls, either manually
by setting the proper HTTP statuses or more automatically and powerfully with the
Redirector class.
We also discussed performance and modularization aspects in order to deal with
applications growing in size and complexity. We looked at HTTP built-in features such
a conditional method processing, entity compression, and caching support. We also
introduced Restlet-specific features such as the server dispatcher, the internal router,
and the RIAP pseudoprotocol to communicate optimally inside a Restlet component.
Youll now continue exploring further Restlet Framework possibilities, such as
deployment in cloud computing, web browsers, and smartphonesand innovative
semantic web support.

Best design practices

When using any persistence solution with Restlet, you should try loading and storing
the state of your resources each time a ServerResource instance is created in order to
process a new call. The goal is to respect the stateless constraint of REST.
This constraint doesnt mean that your application cant have state, but that the
conversation between clients and servers shouldnt be driven by out-of-band information such as cookie-based sessions promoted in the Servlet API.
For efficiency reasons you should consider putting in place database connection
pools and data caches in your Restlet application subclasses, accessing those mechanisms by casting the result of the ServerResource#getApplication() method. Another
option to share state between several resource instances is via the parent Context
instance, which contains a map of attributes.
When dealing with transient data, such as a shopping cart or transactions running
across several web pages, you should rethink your application design to turn this data
into resources, such as a shopping cart resource with a specific URI. The state of those
resources might be stored in a database like other resources, maybe with a shorter lifecycle but without special treatment.
Far from being a backward step, this stateless constraint can even benefit your end
usersthey wont experience the typical session expiration issue when taking too long
to complete a purchase order, for example.

199

7.6.3

Summary

ZZZLWHERRNVLQIR