199 Summary 7.6.3 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 doesn’t mean that your application can’t have state, but that the conversation between clients and servers shouldn’t be driven by out-of-band informa- tion 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 mecha- nisms 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 life- cycle but without special treatment. Far from being a backward step, this stateless constraint can even benefit your end users—they won’t experience the typical session expiration issue when taking too long to complete a purchase order, for example. 7.7 Summary 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 manipu- lated 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 disadvan- tages 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. You’ll now continue exploring further Restlet Framework possibilities, such as deployment in cloud computing, web browsers, and smartphones—and innovative semantic web support. ZZZLWHERRNVLQIR ZZZLWHERRNVLQIR
