Client/server communication based on REST

As mentioned previously, the communication interfaces between the backend system and the client application are implemented as RESTful services. To better understand what this means and implies, this subsection begins dening web services and the REST con-cept. It then explains how RESTful web services are characterized and designed before outlining how they are implemented in the project.

Web services

Web services are software applications that can be accessed remotely using a set of open protocols and standards to facilitate communication and data exchange between hetero-geneous applications and systems in distributed environments. They share business logic, data and processes through a programmatic interface across a network in real time, with-out human intervention and in a interoperable way among dierent applications running on dierent platforms. Normally, a web service is identied by a URL and the client interacts with it via a web server.

Two main styles of web services can be distinguished today:

• REST web services, on which this subsection focuses;

• SOAP-based or message-oriented web services, which use theXML,SOAP,WSDL andUDDIopen standards. The architecture of this type of web services is based on sending XML messages, usually containing a call to a method, in a specic SOAP format. XMLis used to tag the data,SOAPto describe the message format, WSDL to describe the service available and UDDI to list what services are available.

REST

REST is a term coined in 2002 by Roy Fielding in his doctoral dissertation [Fie00] to de-scribe an architectural style of networked systems that is stateless and resource-oriented rather than method centric. REST refers to a collection of network architecture princi-ples (constraints), which dene identiable resources¹ and a uniform set of methods for accessing and manipulating the state of those resources. The term stands for REpresen-tational State Transfer, which Fielding explains as follows: When the client requests a resource, he receives a representation of the resource, which places the client application in a state. When the client clicks on a hyperlink, another resource is accessed, whose representation places the client application into another state. Thus, the client appli-cation changes (transfers) state with each resource representation. In other words, a REST-based architecture is fundamentally a client-server architecture, where clients and servers communicate primarily through the transfer of representations of resources using a standardized interface and a stateless communication protocol, typically HTTP.

The major and only relevant instance of theRESTstyle as a whole is the web architecture, wherein resources are identied by URIs and theREST uniform interface is instantiated by the HTTP verbs. In fact, the REST architecture is modelled after the way data is represented, accessed, and modied on the web. Therefore, in a RESTarchitecture, data and functionality are considered resources, and these resources are accessed using URIs, typically links on the web. The resources are acted upon by using the set of simple and well dened operations of the HTTP protocol. As a result, systems adhering to the RESTprinciples work well in the context of the web. Such systems that follow theREST principles are referred to as RESTful and tend to be simple, lightweight and have high performance.

RESTful web services

A RESTful web service [LR07] is a web application built upon the REST architecture.

RESTful web services adhere to a set of constraints and architectural principles that include the following:

• Client-server architecture based on a pull-based interaction style.

• Stateless communication, i.e. each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server, as stated in Section 5.1.3 of [Fie00].

• Named resources: the architecture is build from resources that are uniquely

identi-ed byURIs and manipulated by exchanging representations of them.

1A resource is a conceptual entity, in fact anything that can be named or referred to with a link (e.g.

article, picture, service, etc.). It is identied by a resource identier such as anURIon the Web and a concrete manifestation of the resource is called a representation.

4.5. Technical solution description 80

Listing 4.1: XML representation of the customers list resource

• Interconnected resource representations: the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another.

• Uniform interface: all resources are accessed with a generic interface that typically comprises the four main HTTP methods (POST, GET, PUT, DELETE) mapping the so-calledCRUDactions (CREATE, RETRIEVE, UPDATE, DELETE) respec-tively. These actions are considered as the most important operations performed on data.

• Layered components: intermediaries, such as proxy servers or cache servers can be inserted between clients and servers to support performance, security, etc.

• Cache: responses must be capable of being cached to improve network eciency.

RESTful web services also dene the supportedMIME type of the data.

To create RESTful web services in a REST network such as the web, the following key design principles should be applied stepwise:

• Identify all conceptual entities (resources) that should be exposed as services.

• Give every resource an ID by creating a URL for each resource. Resources should be nouns, not verbs (e.g. http://www.server.com/parts/00234).

• Categorize the resources according to whether clients can just receive a represen-tation of the resource (GET) or whether clients can modify (add to) the resource (PUT). For the former, the resources should be accessible using an HTTP GET.

For the latter, they should be accessible usingHTTP POST, PUT, and DELETE.

• Put hyperlinks within resource representations to enable clients to obtain more or related information (linking resources together).

• Design to reveal data gradually.

Here is a small example of a web service implemented in a RESTful fashion that enables its clients to get a list of customers and detailed information about a particular customer.

The web service makes available a URL to a customers list resource (e.g. http://www.

customers-server.com/customers). When submiting thisURL, a document containing the list of customers is generating transparently to the client and returned. Listing 4.1 shows the document received by the client, assuming that it has been determined through content negotiation that the client wants anXMLrepresentation of the resource. It can be noted that the customers list has links to get detailed information about each customer, which is a key feature of REST. This allows the client to transfer from one state to the next by choosing one of the URLs in the response document.

The client can then request information about a customer and so on, and each response document will allow the client to drill down to get always more precised information. If the service happens to provide the functionality of updating costumer data, the client would have to post an XML or JSON document containing the changed data to the customer URI.

REST vs SOAP

The RESTand the SOAPstyles of web service share many characteristics but also dier in several signicant ways. Like RESTful web services, SOAP-based web services are designed to be platform and programming language independent, lightweight, accessible via URIs and typically use HTTP as the underlying protocol. In both architectures, clients and servers are loosely coupled, which means that they interact with a limited set of assumptions about each other. However, REST has the advantage of transmiting domain-specic data overHTTP without an additional messaging layer. SOAP operates from a single URI with methods being invoked from within the request payload, which actually fails to use URIs as they were designed to be used. On the other hand, REST provides a uniform resource identifying model (a unique URI for each resource) and a uniform and reduced set of methods, so that, given aURI, anyone already knows how to access it. Table 4.1 compares both technologies by giving their main characteristics and pointing out their advantages and disadvantages. REST web services have been largely developed to overcome some of the perceived drawbacks ofSOAP-based web services. For a comprehensive comparison of both technologies, the reader should refer to [PZL08].

RESTful web services implementation in the project

The SAP backend system exposes its services through RESTful web services addressed over theHTTPprotocol in terms ofURLs. These RESTful web services are implemented as ABAP² classes and data is transferred in the JSONtext format.

The SAP system consists of an SAP NetWeaver Application Server (SAP NW AS), a component of the NetWeaver³ solution [62] that works as a web application server to SAP solutions. This means that it can accept HTTP requests from any web client, process the requests and send a response back to the client. For this purpose, the SAP NW AS implements a layered component-based architecture allowing the requested services to be properly determined and executed. The component that intercepts incoming web requests and deals with the TCP/IP connections is the Internet Communication Manager (ICM), which enables the SAP NW AS to communicate with the Internet via HTTP, HTTPS or SMTP. The ICM forwards the request to the Internet Communication Framework (ICF), which handles access control, authentication and dispatching of

2ABAPis a proprietary programming language developed by SAP AG. It is designed to create large-scale business applications for SAP systems and is supported and used by SAP Netweaver, the integration platform of SAP applications. In the late nineties, ABAP extended to a fully featured OO language, calledABAPObjects.

3SAP NetWeaver is a service-oriented application and integration platform that provides development and runtime environment for SAP applications. SAP NetWeaver is built using open standards and industry de facto standards and can interoperate with technologies such as Microsoft .NET, Sun Java EE, and IBM WebSphere.

4.5. Technical solution description 82

RESTSOAP Characteristics •Denesomeresourcesandtheywillhavethesemeth- ods. •Facilitatestheintegrationofnewapplicationsintoan existingsystems. •Uniformresourceidentifyingmodel(auniqueURIfor eachresource). •Uniformandreducedsetofmethods. •Transmitsdomain-specicdataoverHTTPwithoutan additionalmessaginglayerviaasimpleCRUDinterface. •GivenaURIanyonealreadyknowshowtoaccessit.

•Denesomemethodsthatdosomething. •Addressingisservicespecic:thewebserviceisidenti- edbyspecicbusinessmethods. •AddsanextralayerofabstractionontoHTTPrather thatusingtheprotocolasitwasdesigned. •OperatesfromasingleURIwithmethodsbeinginvoked fromwithintherequestpayload,whichfailstouseURIs astheyweredesignedtobeused. Pros •Languageandplatformindependent. •MuchsimplertodevelopthanSOAP. •Requireslessclient-sidesoftwaretobewrittenthatother approaches,becauseasinglebrowsercanaccessanyap- plicationandanyresource. •Smalllearningcurve,lessrelianceontoolsandvendor software. •Concise,noneedforadditionalmessaginglayer. •CloserindesignandphilosophytotheWeb. •Providesbetterlong-termcompatibilityandevolvability characteristicsthanSOAP.

•Language,platform,andtransportindependent. •Designedtohandledistributedcomputingenvironments. •Istheprevailingstandardforwebservices,andhence hasbettersupportfromotherstandards(WSDL,WS- *)andtoolingfromvendors. •Built-inerrorhandling(faults). •Extensibility. Cons •Assumesapoint-to-pointcommunicationmodel,thus notusablefordistributedcomputingenvironmentwhere messagemaygothroughoneormoreintermediaries. •Lackofstandardssupportforsecurity,policy,reliable messaging,etc.,soservicesthathavemoresophisticated requirementsarehardertodevelop. •TiedtotheHTTPtransportmodel.

•Conceptuallymoredicult,moreheavy-weightthan REST. •Moreverbose. •Hardertodevelop,requirestools. Table4.1:RESTvsSOAP

Figure 4.6: Server components involved in the processing of REST service requests

HTTP methods REST operations

GET DO_READ

POST DO_INSERT

PUT DO_UPDATE

DELETE DO_DELETE

PROPFIND DO_PROPFIND

Table 4.2:HTTP methods and their corresponding REST interface methods

incoming requests. With the help of theURL, theICF decides which handler to call for further processing. A request for a REST service, like in the case of the oine client, is dispatched to theHTTP RESThandler. This handler is mainly responsible for delegating the processing of the request to the corresponding REST service class. To accomplish this, the handler rst needs to map the request HTTP verb to the corresponding REST interface method (see Table 4.2). Then, based on the URI, it looks for the corresponding service class in the Customizing RESTful Services table. Once the class is determined, the HTTP handler can invoke the REST method on the service class, as every service class implements the REST interface. The handler also takes care of returning the resulting data as an HTTP response and of the JSON-ABAP-JSON conversions for the service class, which handles the specic data processing. Figure 4.6 illustrates the previously described components involved in the processing of web requests. In consequence of the server structure, the process of processing a request to a RESTful web service is broken down into the following activities, as depicted in Figure 4.7 (designed mainly by Nicola

4.5. Technical solution description 84 Fankhauser):

1. Request comes over HTTP and is captured by theICF service.

2. ICF delegates the request to the HTTP handler.

3. The handler takes over the processing from here and performs the following actions:

• Analyzing the Request

The handler parses the URI, selects the corresponding service class, instanti-ates the class and maps theHTTP verb to the interface operation.

• Preparing the service class

The HTTP body is converted from JSON to an ABAP structure and passed to the service class.

• Calling the corresponding service class method

• Retrieving the returned ABAPdata structure

• Processing the returned content

In case of success, the ABAP structure is converted in JSON, otherwise the exception is converted into the corresponding HTTP status code.

• Building and sending theHTTP response

It should be noted that in order to know how the data is returned and formatted, the client can send requests using theHTTPPROPFIND method to retrieve the service meta-denition. Originally, this method was designed as an HTTP extension for Distributing Authoring (WebDAV)⁴ to retrieve the properties dened on a resource identied by the requestURI. The RESTful web services implemented in this project take up this idea by supporting this method for similar purposes.

An example of a RESTful web service⁵ made available by the SAP backend system⁶ is the ^userinfo REST service, which allows the client to retrieve system user details by requesting a particular user resource from the service, obviously with the HTTP GET method. Figure 4.8 gives the URI used to get the details of the user named itefrz. As shown in the picture, the rst part of theURIis parsed by theICFto identify the handler to which the request should be forwarded. The second part is analysed by the handler itself, which uses the customizing table to determine the service class to instantiate.

The table entry for the registered service is shown in Figure 4.9. After mapping the HTTPmethod to theREST operation, the handler knows that it has to call the^do_read() method of this service class. As indicated in the customizing table entry, this service class denitely provides an implementation of the^do_read()method, whoseABAPcode is given in Listing 4.2. An excerpt of the response returned by the service inJSON format for the URI given in example is illustrated in Listing 4.3.