XML Technologies for RESTful Services Development Cornelia Davis Tom Maguire EMC Corporation EMC Corporation Santa Barbara, CA White Plains, NY +1 (805) 560 9039 +1 (914) 461-3522 [email protected] [email protected] ABSTRACT an extreme position, rather, we expect that there will be For the last several decades the predominant architectural style for differences between the physical model and the logical one. These the implementation of data-centric applications has had a transformations are often necessary to provide a variety of relational database at the core, procedural code implementing the projections (though the RESTful services) of the underlying data, application services and an object-oriented API. More recently to support more than one media type, or to allow the physical the API has transitioned, via a slight detour through SOAP-based format to be optimized for performance or other run-time web services, to a RESTful style, however what lies beneath that characteristics. In our work we have focused on the RESTful interface has been slower to take a new approach. In this paper services and the server implementation with little attention given we argue that upgrading that which is under the covers to an to the XForms or other consumer-side user interface. XML-centric technology stack will result in a system that is easier We have produced a framework that allows a developer to create to build, test and maintain. Further, these technologies are a step a set of resource-oriented services with most of the toward making construction of such systems available to non- implementation achieved using XML-based technologies. We programmers. We present an XML RESTful Services framework have found these technologies to be very effective at addressing that provides mechanisms to address all of the key aspects of many requirements specific to RESTful services. Content systems built in the RESTful architectural style. negotiation is straight-forward via a declarative programming model. Resource hyperlinks are generated via the same Categories and Subject Descriptors declarative approach. Common patterns for resource operations D.2.11 [Software Architectures]: Patterns, Languages, Service- are effectively captured and processing of composite resources is oriented architecture. D.3.3 [Language Constructs and done via an XML pipelining model. We have used the framework Features]: Patterns, Frameworks. D.3.2 [Language to build several systems, including an IHE-compliant registry [15] Classifications] Data-flow languages, Nonprocedural languages, for medical records, and have found that taken collectively, these Very high-level languages. D.1.m [Programming Techniques]: XML technologies provide a solid platform with which REST Declarative. D.2.3 [Coding Tools and Techniques]: Standards. architectural concerns are effectively addressed. General Terms Design, Human Factors, Languages. Keywords REST, XML, XProc, XQuery, XSLT, HATEOAS, XRX, XML Database, Linked Data 1. INTRODUCTION The term XRX [10], stands for XForms [2] on the client, RESTful services and XQuery [1] on the server. At its core it is a design approach that uses XML as the model for the application entities, and other XML technologies, specifically XForms and XQuery, for the application UI and for interface to the persistence layer, respectively. At the extreme, XRX is a no-transformation approach where there is no difference between the logical model for entities and the physical one; that is, the resource representations are persisted in exactly that form in the database. While our work has been inspired by XRX, we do not take such Figure 1 - XML-Centric Services Implementation Permission to make digital or hard copies of all or part of this work for Figure 1 shows the main elements of a RESTful service personal or classroom use is granted without fee provided that copies are implementation using our framework. Resources are defined as not made or distributed for profit or commercial advantage and that Java classes, with methods corresponding to the operations of the copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, uniform interface; we leverage web services frameworks such as requires prior specific permission and/or a fee. Spring MVC or those that support the Jax-RS standard [6], such WS-REST 2011, March 2011, Hyderabad, India. as Apache CXF [14] for the runtime interpretation of these Copyright 2011 ACM 978-1-4503-0623-2/11/03…$5.00. resource classes. Instead of crafting the implementation of the service in Java, however, we leverage XProc [12], XQuery and Assuming the first media type implemented was application/xml, XSLT [9], and for data persistence we use an XML database. if the developer now wishes to provide support for a second media Finally, we leverage the core Spring Framework [8] as the type, say, application/atom+xml, the Java implementation of that mechanism whereby the developer binds each of the method must now include code that takes the result set from the implementation artifacts together. SQL query and generates an Abdera Feed Object, for example, We chose to embrace a Java-based framework for the top layer of which is then marshaled to XML by Abdera [13]. the RESTful services implementation for several reasons. First, As you can see, a very simple service implementation has a these frameworks provide a robust implementation of a good complex set of transformations that must be performed; portion of the elements of a RESTful services implementation, transformations that are not concerned with the details of the including a server-side HTTP implementation plus support for specific domain for which the services are being built, yet they URI templates, uniform interface and content negotiation. require a great deal of work to construct, test and maintain. We Second, the models offered by these frameworks are already call these non-value-added transformations. widely embraced by the developer community. Finally, the Spring Framework provides a Java-centric platform, also widely 2.2 XRX-Style Approach adopted, for binding the pieces of an implementation together, via To contrast the above to the implementation approach offered by approaches such as dependency injection and Model View our framework, let us again consider the flow through a services Controller (MVC) [7] support. You will note, however, that implementation. Because we are using the same framework for because the actual services implementation is pushed into the the outermost layer of the RESTful service, that flow begins just XML technologies stack that the method implementations are as it did above. rather boilerplate. This leaves open the possibility that the Java A received request is inspected and the appropriate POJO and code could be generated from an expressed model of the RESTful method is identified. The method signature allows any incoming services, such as might be offered with the Web Application request body to flow into the method in the form received by the Description Language (WADL) [5]. servlet (probably an input stream) so no transformation is needed. Of course, the pieces of the implementation must execute within Within the Java method the XProc pipeline is executed, passing in the context of the service invocation, which is introduced into the any request body. The XProc pipeline may implement a system at this Java layer. Context parameters, such as the URL of transformation that converts the logical resource representation the resource, HTTP headers and the body are passed to the XProc into a physical one, although in many cases the necessary pipeline and, in turn, they are passed down to the steps within the transformations are simple and may be handled as a part of the pipeline. XQuery. The XQuery is executed to read and/or write data to the persistence layer, an XML database (no XML to relational After contrasting the traditional, Java-based implementation transformation!), and the query result may be transformed from approach to the XML-centric approach proposed through this the physical representation to the logical one. The XML response research, we will present details of how each element of the from the XProc pipeline is returned to the Java method and in turn RESTful services implementation is built with special coverage returned as the resource representation. given to the topic of Hypertext As The Engine Of Application State, HATEOAS [3]. After summarizing the steps taken when When we wish to add support for a second media type, we need using the framework to implement RESTful services, we conclude only supply an alternate stylesheet for the transformation between by reviewing how needs particular to RESTful services are logical and physical models and configure the same XProc addressed with the framework. pipeline with the new stylesheet. In the purest sense an XRX-style implementation is 2. CONTRASTING TWO APPROACHES transformation free; that is, there is no difference between the In order to motivate the development of the XML REST logical and the physical model. Taking this approach would seem Framework, we briefly review what goes into an application to offer a great advantage in terms of the simplification of the constructed in a traditional style and contrast that to an XRX-style implementation, however, in most real-world scenarios this would approach. have some negative effects such as poor performance or tight 2.1 Traditional Approach coupling between the service implementation and the client. Let us consider what happens in satisfying service a request to a When supporting multiple media types, transformations are RESTful service implemented predominantly in Java, using a simply unavoidable. So even with the XRX-style approach relational database for persistence and CXF, Jersey or Spring transformation are necessary, however, they address a domain- MVC for the interface layer. specific need and are arguably more easily constructed and configured.