Modeling Behavioral RESTful Web Service Interfaces inUML

Ivan Porres and Irum RaufÅbo Akademi University, Dept. of Information Technologies,Turku, Finland

ivan.porres@abo.fi,irum.rauf@abo.fi

ABSTRACTA web service interface contains information about the namesof the operations that can be invoked on the service and theinput and output parameters of these operations. The WebApplication Description Language (WADL) is a language todescribe the interface of a web service that follows the Rep-resentation State Transfer (REST) architectural style. Cur-rently, WADL descriptions do not describe the behavioral se-mantics of the operations neither ensure that the publishedinterfaces follow the REST style, that is they are REST-ful. In this paper, we present an approach to model thestructural and behavioral interface of a RESTful web ser-vice using UML class and UML protocol diagrams. Thesemodels lead to RESTful interfaces that describe the behaviorof operations in terms of preconditions and postconditions.The contracts can then be published in an extended versionof the WADL language and used for documentation, stubgeneration, testing and monitoring purposes.

KeywordsREST, contract, UML, protocol state machine, WADL, be-havioral interface

1. INTRODUCTIONA web service provides a programmatic interface to a com-

puter system offered over a network using standard web pro-tocols. Web services are consumed by other programs andservices. This is unlike the document web or an interactiveweb application that is designed for human users who searchfor a particular information, receive it in a format that theyunderstand and then use it manually as input to anothersoftware or machine for further processing.

The Representational State Transfer (REST) architecturalstyle has become a popular approach to design web ser-vices. It emphasizes on generality of interfaces and scala-bility of component interactions. A web service that followsthe REST style is often called a RESTful web service.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SAC’11 March 21-25, 2011, TaiChung, Taiwan.Copyright 2011 ACM 978-1-4503-0113-8/11/03 ...$10.00.

Many RESTful web services present simple interfaces tocreate, retrieve, update and delete information from a database(also called CRUD interfaces). However, REST is not lim-ited to simple CRUD interfaces. It is possible to create webservices with a complex application state that still followthe REST architectural style. In these cases, it is importantto create and publish behavioral service interfaces so otherdevelopers can understand how to use a service correctly.The interface of a web service advertises the operations

that can be invoked on it. A web service developer lookingfor a particular service finds the service over the web andintegrates it with other services by invoking the advertisedoperations and providing it the required parameters. Theseoperations may require a certain order of invocation or theremay be special conditions under which they can be invoked.This information, together with the expected effect of anoperation forms part of the behavioral interface of a service.The behavioral interface can also be used to test a serviceimplementation and for service discovery. More advancedscenarios, such as automatic service discovery and servicerepositories rely in formal descriptions of services.There is a proposal for a description language for REST-

ful web services named the Web Application DescriptionLanguage (WADL). It is used for publishing RESTful webservice interfaces and provides machine-processable descrip-tion of the interface without cluttering it with too many de-tails [9]. Currently, RESTful architectural style and WADLare being widely adopted in the web and have numeroususers, including enterprises such as Google, Yahoo, Amazonand Flicker.The information about the interface of a web service in

WADL is syntactic and does not state anything about its se-mantics, how a service should be invoked and behave. Also,WADL is not actually restricted to RESTful services andcan be used to describe services that do not follow this ar-chitectural style completely.In this paper, we study how to use UML to model and

describe behavioral interfaces for web services that followthe REST style. The objective of the work is twofold. First,to provide a way to describe behavioral services interfacesthat specifies how to use a web service correctly and whatare the expected results of using a web service. Second, toprovide a modeling approach that ensure that the designedinterface follows the REST style.To demonstrate our approach, we use as example an imag-

inary hotel room booking (HRB) service. The service allowsa client to book a room, pay for the reservation, and can-cel it. It is a simplified pedagogical example, but it shows

1598

how to design a REST interface for a service with a complexapplication state.

The paper is organized as follows. Section 2 gives anoverview of the approach. The conceptual resource modeland the behavioral model are presented in Section 3 and 4,respectively. Section 5 presents the generation of contractsfrom models and behaviorally enriched WADL. Section 6shows how these models lead to RESTful interfaces. Section7 discusses the application of these behavioral interfaces. Insection 8, related work is presented and Section 9 providesconclusion of the paper along with the future work.

2. OVERVIEWIn this article we propose an approach that creates REST-

ful web services by construction. We use UML class dia-grams and UML protocol state machines with state invari-ants to model a REST web service. These models can alsobe used to generate a contract as its behavioral interface.

The REST architectural style is defined by four attributes.In the context of a web service these attributes are:

• Addressability: The REST style requires that any im-portant piece of information related to a service shouldbe exposed as a resource and each resource should beaddressable via a URI.

• Connectedness: This requires that resource represen-tation contains links to other resources.

• Uniform Interface: All resources are manipulated us-ing the standard HTTP methods. The HTTP GET,POST, PUT and DELETE are used to retrieve infor-mation from a resource or change its state.

• Statelessness: There is no hidden session or state in-formation. Besides, the effects of the POST, PUT andDELETE operations should be observable in the af-fected resources.

Any RESTful web service should comply with these fourattributes. Therefore the attributes become requirementsover the design of the web service interface.

The structural and behavioral UML models proposed inthis article for a web service comply with these requirementsand lead to RESTful interfaces.

UML is a standard modeling notation that provides repre-sentation of the system in an abstract manner from differentperspectives. It also serves as part of the specification doc-ument.

The starting point of our approach is an informal web ser-vice specification in natural language. This specification isused to create a conceptual resource model and a behavioralmodel of the web service. The conceptual resource model isrepresented diagrammatically using a UML class diagram.It represents the resources involved in a service and theirconnections and it tackles the addressability and connected-ness requirements of the REST style. The behavioral modelof the service is represented using a UML protocol state ma-chine with state invariant. A protocol state machine con-tains a number of states and transitions. Each transitionis triggered by a method and each state should have an in-variant. By constraining the allowed transition triggers tothe standard HTTP method we comply with the uniform

interface requirement and by defining the state invariantsusing addressable resources we comply with the statelenessrequirement.A contract specifies the pre- and postconditions for the

methods of a class. The role of contracts as behavioral inter-faces has been investigated for software classes [15, 7, 5] andalso in the domain of web services [10, 8]. A contract bindsuser of the service to pose a valid request and constrains itsprovider to provide the correct behavior. We show how thepre-and postcondition of each service request can be gener-ated from the proposed UML models and how these pre- andpost conditions can provide behaviorally enriched WADL in-terface.Our approach can generate implementation stubs and also

extract information from behavioral model of a web serviceand assert it in syntactic interface of a web service. Theextended WADL descriptions provide behavioral interfacespecifications in a machine-processable format.The developed models and contracts can be used to im-

plement the actual web service using a design by contractapproach [15]. They can also be used to test an existingimplementation by generating test cases automatically fromthe contracts [13, 1, 15]. Finally, users of a web service canuse the models and contracts as detailed documentation onhow to use a service correctly.The service can be described using the UML language or

using the WADL extended with preconditions and postcon-ditions. UML models facilitate the design process as theycan be read and understood by human developers. TheWADL descriptions are in a machine readable format thatcan be processed by machines for extracting the requiredinformation.In the next section we present in detail how a conceptual

model is developed for a RESTful web service.

3. CONCEPTUAL RESOURCE MODELThe concept of a resource is central to Resource Oriented

Architecture. Any important information in a service in-terface is exposed as a resource. A resource is somethingthat can be referred to and can have an address. Resourcesin a resource oriented architecture are analogous to objectsin object-oriented paradigm [18] or entities in the entity-relationship model.However, unlike objects and classes in OO paradigm, the

resources in resource oriented paradigm are designed withthe mind set to expose relevant information for manipula-tion instead of hiding it [19]. Also, in a RESTful interface,resources do not have different access methods, instead thestandard HTTP methods are used. Our approach uses fourHTTP methods i.e, GET, PUT, POST and DELETE, forretrieving and updating data in a resource.We use UML class diagram to represent the structure and

connections of the resources in a RESTful web service. AUML class diagram represents mainly classes and their asso-ciations. An association defines a relationship between twoclasses by which one class knows about the other class [20].The complexity of a service can be reduced by increasing

the number of resources. This results in decoupling of in-formation. A resource can also be a collection resource thatcontains a group of other resources. Figure 1 shows a con-ceptual model of the HRB RESTful service. We have brokenour HRB service into two collection resources (bookings and

1599

rooms) and five other resources (booking, room, payment,pconfirmation and cancel).

3.1 Mapping Class Diagrams to ResourcesThe elements of a conceptual model are mapped to the

resources of a RESTful web service as follows:

• Each class in the UML diagram represents a resource.

• Classes with the << collection >> stereotype repre-sent collection resources.

• The UML class attributes are the data contained inthe resource. This data should appear in the resourcerepresentation, i.e. an XML document or a JSON se-rialized object.

• The UML associations represent the connections be-tween resources.

• The role names on association ends map to the relativenavigation path from one resource to another.

• The association multiplicity refers to the number ofresources that can be related to a resource on the otherend of the association.

Figure 1 shows representation of resources in the HRB ser-vice. For example, room resource contains three attributesi.e. rid, rType and floor. Room ID(rid) and floor(floor)areinteger values and Room Type(rType) is a string value. At-tributes are modeled as a public attribute as the representa-tion of a resource is available for manipulation.

3.2 Collection Resources and AddressabilityIn Figure 1, bookings and rooms represent collection re-

sources with the stereotype collection and are linked to childresources, booking and room, respectively. A collection re-source has a cardinality of more than 1 on the associationend of a child resource. A GET method on a collection re-source returns a list of all the child resources it contains. Forexample, a GET method on bookings will give a list of allthe booking resources that it contains.

Collection resources are also used as the starting point ofthe paths to address each resource. Starting from a collectionresource, we can access other resources by navigating thesuccessive associations. Paths visiting the same associationmore than once are not valid. In our example, the followingpaths are valid.

The REST style requires that all resources should be ad-dressable. In our context this requirement is fulfilled if eachresource can be reached from at least one collection resourceby navigating one or more associations.

3.3 MethodsA UML class diagram allows us to define a number of

operations for each class. Since a RESTful web service pro-vides uniform interface for all resources, most classes wouldonly have from one to four methods names GET, POST,PUT and DELETE. We do not consider necessary to addthis information in the conceptual model.

4. BEHAVIORAL MODELThe purpose of the behavioral model is to describe the

behavioral interface specifications of a RESTful web service.It shows the sequence under which operations should be in-voked, the conditions under which they can be invoked andthe expected results.Since we are describing RESTful web interfaces, the only

allowed operations are GET, POST, PUT and DELETE onresources.The GET method retrieves a representation of a resource

and it should not have side effects. Due to the addressabilityrequirement, it should be always possible to invoke a GETmethod over a resource. For example, GET(/bookings/{bid}/payment) andGET(/bookings/{bid}/rooms/{rid}) are HTTPGET methods on the resources payment and room, respec-tively. Whenever a GET method is called on a resource, itgives the representation of resource as a response. In prac-tice, the access to resources may be restricted by an authen-tication and access control mechanism.The POST, PUT and DELETE methods can have side ef-

fects. In our hotel booking example, one of the operations ofthe service is to pay a booking. This is achieved by a HTTPPOST request over a payment resource. However, a paymentcan only be accepted if it is connected to a room bookingand a booking can only be paid once. Also, a booking canbe canceled, but not while the payment is being processedby a financial service. We need to define all these conditionsin the behavioral interface of the service.We propose to use a UML protocol state machine with

state invariants to describe the allowed operations in a webservice. We consider that a UML protocol state machine issuitable for representing the behavior of a web service as itprovides interface specifications with information on condi-tions under which methods can be invoked and the expectedoutput from them.A UML protocol state machine contains mainly states and

transitions. We require that each state has a state invariantthat is defined as a boolean expression. We then say thata state is active if and only if its state invariant evaluatesto true. A state may contain other states and is called acomposite state. In such a case, the actual state invariant ofthe contained state is given by the conjunction of the stateinvariant specific for the contained state and the state invari-ants of all the states that contain it. These state invariantswithin a composite state should be mutually exclusive. Thatis, only one state within a region of a composite state canbe active at a time.A transition is an arc from one or more source state(s) to

one or more target state(s) labeled with a method name anda guard. If the source states are active, the guard is true andthe method is invoked, then the transition may be fired andas a consequence the target state(s) become active. Whenno guard is shown in the transition it is assumed to be true.In our behavioral model, the transition triggers can only

be defined as POST, PUT or DELETE operations over re-sources described in the conceptual model. The guards andthe state invariants can be defined only using informationfrom the resources and request parameters.When we invoke an HTTP GET method on a resource,

it returns its representation along with the HTTP responsecode. This response code tells whether the request went wellor bad. If the HTTP response code is 200, this means that

1600

/ bookings /{bid }// bookings /{bid }/ cance l // bookings /{bid }/payment// bookings /{bid }/rooms/{ r i d }// bookings /{bid }/payment/ pconf i rmat ion //rooms/{ r i d }//rooms/{ r i d }/ booking//rooms/{ r i d }/ booking/ cance l //rooms/{ r i d }/ booking/payment//rooms/{ r i d }/ booking/payment/pconf i rmat ion /

Figure 1: (Left) Conceptual Model for HRB RESTful Web Service. (Right) Resource paths

the request was successful and the referred resource exists.Otherwise, if the response code is 404, this implies that URIcould not be mapped to any resource and the referred re-source does not exist.

We manipulate this information exhibited by the responsecodes and representation of resources by comparing themwith the expected behavior. We use a boolean functionOK(r) to express that the response code of HTTP GETmethod on a resource r is 200. Similarly, the boolean func-tion NOT FOUND(r) is true when the response code ofHTTP GET method on resource r is 404. These booleanfunctions on the resources along with the attributes thatrepresent a resource are used to define a state invariant inour RESTful behavioral model.

For example, consider the state invariant for the state re-served not paid in Figure 2. NOT FOUND(p) checks the re-sponse code for the HTTP GET method on the resource pay-ment. It evaluates to true if response code of GET methodon p for a particular booking ID({bid}) is 404. For the HRBservice to be in state reserved not paid, the state invariantof this simple state is conjuncted with the state invariantsof all the states that contain it.

Our behavioral model shows different states of a RESTfulweb service and gives information on what HTTP methodson a particular resource can be invoked from a certain state.According to Figure 2, the protocol state machine of HRBservice is initiated by the HTTP POST method on the book-ings resource. Whenever a PUT, POST or DELETE methodis called on a resource it changes the state of the applicationin the behavioral model. A booking can be canceled fromcomposite states reserve and pay and confirmation info anda booking can be deleted only if it is canceled. A bookingcannot be canceled if it is waiting for the payment confirma-tion from a third-party service.

A guard condition on the transition specifies the condi-tion required to invoke an HTTP method on a resource. Forexample, consider guard [pc.confirm==true] for the methodPOST(pconfirmation) in Figure 2, where pc refers to the rel-ative navigation path to resource pconfirmation. This guardspecifies that the POST method on pconfirmation can be

invoked if the resource representation of pconfirmation con-tains true value for the confirm attribute.

4.1 Stateless State Machines?Using a state machines to model a stateless interface may

seem an oxymoron. In the context of a RESTful service,statelessness is interpreted as the absence of hidden informa-tion kept by the service between different service requests.In that sense, a RESTful web service should exhibit a state-less protocol. Also, there is no sense of session or sequenceof request in a true RESTful service.On the other hand, state machines have a notion of ac-

tive state configuration, that is, what states are active at acertain point of time. If an implementation of an interfacedescribed using a state machine would have to keep the ac-tive state configuration between different requests, then thiswould break the statelessness requirement of the RESTfulservice.However, our approach does not actually require that a

service implementation keeps any additional protocol state.In our approach a state is active if its invariant evaluates totrue, but the invariants are defined using addressable appli-cation resources. Therefore an implementation of a servicecan determine the active state configuration by querying theapplication state. There is no need to keep any additionalprotocol state.Determining what is the active state configuration of the

interface state machine every time that a service implemen-tation has to fulfill a request may be a slow task in the caseof complex interfaces with many states. However, in practiceit is not necessary to explore all states in the state machinebut only the source states of the transitions that can betriggered based on the current request. We show in the nextsection how we can do that by computing the precondition(and postcondition) of each method request.

4.2 Mapping Protocol State Machines to MethodPre- and Postconditions

In this section we show how to extract the contract in-formation from a UML protocol state machine with state

1601

Figure 2: Behavioral Model for HRB RESTful Web Service

invariants. The contract contains the precondition and post-condition for each method that triggers a transition in thebehavioral model.

The precondition of a method states under what condi-tions a method can be triggered. We say that the precon-dition of a method m is satisfied when the state invariantsof all the source states of transition t are true along with itsguard condition.

In a similar manner, if a method m triggers a transitiont in a behavioral model, then its post-condition is satisfiedwhen the state invariants of all the target states of transitiont are true along with the postcondition annotated on thetransition t.

We use the formalization of the structure and semanticsof the UML protocol state machine presented in [16]. Thisformalization supports formal definitions for generating pre-and post-conditions for class methods. We extend this workby generating contracts for HTTP methods from our behav-ioral models for RESTful web services.

In order to shorten the description of the contract we usepath variables to represent the address of a resource. First,the precondition for a method that triggers a transition inthe behavioral model is presented. The precondition of amethod m is given by taking into account all the transitionsthat are triggered by m. If it is a simple transition, thenthe state invariant of its source state is conjuncted with the

guard of the transition. In case the transition is a triggerto more than one transition, with true guards, and all thetransitions have different source states, then the precondi-tion is given by taking a disjunction of state invariants of allthe different source states. This implies that the method cantrigger a transition whenever it is in one of its source states.A transition can occur from one state to another if the

method that triggers this transition is invoked and its pre-condition is true. For the transition to be successful, thepostcondition of the transition should also be true after themethod is invoked. This is specified by the implication op-erator that relates a precondition of a transition with itspostcondition.A postcondition for a method is extracted from the pro-

tocol state machine by manipulating the state invariants ofthe target states of transitions and the post-conditions ontransitions. The post-condition of a fork transition, withtrue postcondition, specifies that the state invariants of allits target states are true and for a self-transition, its post-condition ensures that the same state invariants are true thatwere true before invoking the HTTP method.For the details and formal definitions of generating precon-

ditions and postconditions for different elements in a UMLprotocol state machine of a class readers are referred to [16].The postcondition of a transition will be evaluated only

if the precondition for that transition is true. We define as

1602

pre OK(r) the function that gives boolean value of OK(r)on resource r before invoking the trigger method. Similarly,pre pc.waiting, pre pc.confirm and pre NOT FOUND(r) givethe representation of pconfirmation and boolean value ofNOT FOUND(r) before invoking the trigger method, respec-tively.

The excerpt below from the list of high-level contractsgenerated from Figure 2 shows the contracts generated forthe HTTP method POST on cancel resource.

PATHb : bookings /{bid }/r : bookings /{bid }/rooms/{ r i d }pc : bookings /{bid }/payment/ pconf i rmat ionc : bookings /{bid }/ cance l

POST {bookings /{bid }/ cance l }precondition(OK(b) && OK( r ) && NOTFOUND( c ) ) &&(NOTFOUND( pc ) | | OK(pc ) && pc . wai t ing ==

f a l s e ) )

postcondition( pre OK(b) && pre OK( r ) && pre NOT FOUND( c ) ) &&(pre NOT FOUND( pc ) ==> OK (b) && OK( c ) ) &&(( pre OK( pc ) && pre pc . wai t ing == f a l s e ) ==>

OK (b) && OK( c ) )

The conceptual model as shown in Figure 1 and behavioralmodel as show in Figure 2 lead to RESTful interfaces. Thisis explained further in the next section.

5. GENERATION OF BEHAVIORAL WADLSERVICE DESCRIPTIONS

Besides the UML representation of the behavior interfaces,we propose to extend the Web Application Description Lan-guage (WADL) to include information about the behaviorof the methods in a service. Our objective is that this infor-mation is generated automatically from the conceptual andbehavioral models described before.

WADL defines the operations that can be invoked on aninterface and describes the input and output parameters foreach operation. It defines the resources that an applicationcontains and methods that can be called on them. Eachmethod has two attributes name and id, where name is thename of the HTTP method and id is the ID of the methodthat is associated with the HTTP method.

Representing the information in the conceptual model aspart of a WADL service description is a rather straight for-ward task. However, the behavioral model does not mapdirectly to a WADL description since the behavioral modelallows different transitions to be trigger by the same method.In our example, a cancel request can be invoked when the ap-plication is in different states. That is the information aboutwhen a method can be invoked (precondition) and what isits result (postcondition) needs to be computed from thedifferent states in the behavioral model.

5.1 Inserting Pre- and Postconditions into WADLService Descriptions

The high-level contracts are refined with details on rela-tive navigation paths, invoked HTTP methods and the ex-pected response codes. These refined contracts are assertedinto WADL interface. The function pre OK(r) is mappedto a pre GET function and its response code is comparedto 200. The pre GET(r) function gives the stored results of

invoking a GET method on resource r before invoking themethod. In similar manner, a pre NOT FOUND is mappedto a pre GET function and its response code is compared to404.In order to support the behavioral information in the in-

terface descriptions, we have extended the XML schema ofWADL with two elements precondition and postcondition,with an attribute id for each of these elements. These tags,i.e., < precondition > and < postcondition > are assertedabove and under the method tag, respectively. An excerptof a behavioral RESTful interface is shown below for methodPOST on cancel resource.

. . .<r e s ou r c e s base = ”http ://www. example . com/bookings”>

. . .<resource path = ”{ bid}”>. . .<resource path = ”cance l”>. . .<precondition id = ”p r e p o s t c a n c e l ” >

(GET(/ bookings /{bid }/) == sta tu s (200) &&GET(/ bookings /{bid}/rooms/{ r i d }) == sta tu s (200) &&GET(/ bookings /{bid}/ cance l /) == sta tu s (404) )

&&(GET(/ bookings /{bid}/payment/ pconf i rmat ion ) ==

sta tu s (404) ) | |(GET(/ bookings /{bid}/payment/ pconf i rmat ion ) ==

sta tu s (200) &&GET(/ bookings /{bid}/payment/ pconf i rmat ion )#wait ing == f a l s e )

</precondition><method name = ”POST” id = ”cance l”>

<request><param name= ”c id ” type=”xsd : i n t e g e r ” s t y l e

=”query ” /><param name= ”note ” type=”xsd : s t r i n g ” s t y l e

=”query ” /><param name= ”cDate ” type=”xsd : date ” s t y l e

=”query ” /></request>

</method><postcondition id =”po s t p o s t c a n c e l ” >

( pre GET(/ bookings /{bid }/) == sta tu s (200) &&pre GET(/ bookings /{bid}/rooms/{ r i d }) ==sta tu s (200) && pre GET(/ booking /{bid}/ cance l /) ==sta tu s (404) ) &&

( pre GET(/ bookings /{bid}/payment/ pconf i rmat ion ) ==sta tu s (404) ==> GET(/ bookings /{bid }/) ==sta tu s (200) && GET(/ booking /{bid}/ cance l )== 200)

&&(( pre GET(/ bookings /{bid}/payment/ pconf i rmat ion ) ==

sta tu s (200) &&pre GET(/ bookings /{bid}/payment/ pconf i rmat ion )#wait ing == f a l s e ) ==>

(GET(/ bookings /{bid }/) == sta tu s (200) &&GET(/ bookings /{bid}/ cance l )== 200) )

</postcondition>. . .

</resource>. . . .

</resource></resources>

6. RESTFUL BEHAVIORAL INTERFACESAs discussed earlier, a REST interface should exhibit these

four attributes: addressability, connectivity, statelessness anduniform interface. We claim that we can create RESTful in-terface following the approach described in this paper. Ourconceptual resource model and behavioral model lead to webservices that exhibit these attributes and make our interfacesRESTful by construction.We constrain our conceptual model to be a connected

graph such that no resource is isolated. The associationsbetween classes in the conceptual model provide connectiv-ity between the resources. Each resource can be addressedindependently using the navigation directions of associationsand their role names. The role names show the relative nav-igation path between the resources. For example, the navi-gation path to a room that belongs to a particular bookingID(bid) is given as /bookings/{bid}/rooms/{rid}. Thus, eachresource has a URI address providing addressability featureto our conceptual resource model.

1603

Unlike software class diagrams showing static structure ofRPC web services, our conceptual model does not containany method information. We restrict the behavioral modelso that transitions can only be triggered using the standardHTTP methods, providing the uniform interface feature.

In addition, we have created stateful service using state-less service interface thanks to the fact that the applicationstates are defined using state invariants that are defined interms of exposed resources. This information is presented inthe behavioral model of the REST interface, providing thestatelessness feature in our behavioral model.

7. APPLICATIONS OF BEHAVIORAL INTER-FACES

Service descriptions are often used to automatically gen-erate code stubs to invoke the service from a particular pro-gramming language. Another interesting application is thecreation of a service register to publish and discover webservices. Still, a service description enriched with behav-ioral contracts has many other applications that we describebelow.

A web service developer can use the behavioral REST in-terface as a specification to implement the web service. TheUML protocol state machines do not contain executable ac-tions, unlike behavioral state machines, and hence are notexecutable. On the other hand, they provide rich behav-ioral information of an interface. Developers implementinga web service have to manually implement the interface spec-ified in protocol state machine. This require efforts to ensurethat implementation conforms to its behavioral specification.Our approach can be extended to generate implementationsstubs from the presented models in an automated manner.In addition, behavioral specifications can be automaticallygenerated from models and asserted as contracts into pro-grammatic interface of the web service. This work is underdevelopment using Django framework.

A service implementation can use the asserted contractsto validate a request from the client. The preconditions of amethod provide a check on the incoming request. Thus, en-suring whether the conditions to invoke a service method aremet before invoking the method can be an efficient activityin terms of cost and bandwidth. Similarly, a client can ben-efit from the asserted postconditions to validate a responsefrom the server, constraining the provider of the service toensure the functionality that is expected from it.

In order to validate a service, test cases can be generatedfrom the behaviorally enriched interfaces. These test casescan validate the implementation of a web service and thesecontracts can also be exploited for the generation of testoracles. Test oracles are used to determine whether a testhas passed or failed. In the context of test case generationand test oracle generation, we can take advantage of severalefforts done previously to validate the behavior of classesand web services using contracts [8] [7].

We can also use these behavioral web service interfacesto provide a monitoring mechanism. The behavioral specifi-cations can be added as a proxy interface to already devel-oped and deployed web services to monitor their functioning.This facilitates location of the fault in and application by ob-serving the conditions that are not being met and by whichmethods. It can also check for any failure caused by a net-

work fault, late delivery or if a service developer violates acertain pre or post condition of a method by mistake duringimplementation.

8. RELATED WORKSeveral authors have used UML class diagram and other

UML behavioral diagrams to model RPC styled web servicesand their compositions [17].In terms of modeling behavioral specifications of web ser-

vices, Bertolino and Polini have used UML protocol statemachines for specifying the intended protocol of services [2].Protocol state machines are transformed to Symbolic Tran-sition System that is extended with Labeled Transition Sys-tem(LTS) semantics.Modeling of RESTful web services has been addressed in

the work of Systa and her research group [11, 12, 19]. In [11,12], an approach that migrates legacy APIs to RESTful webservices is presented. In [12], Laitkorpi et. al present theprocess that transforms service functionality over differentphases to a RESTful service. This approach is further ex-plored in [19] by Siikarla et al. They provide an iterative andincremental process for the development of model transfor-mations by focusing on the step of transforming informationmodel to resource model.The role of contracts in the domain of web services has

been investigated previously, e.g., [6] [4], etc. In [6], Castagnaet. al present theory of contracts that formalizes the compat-ibility of a client to a service and introduces a subcontractrelation for behavioral typing of web services promoting ser-vice reuse or redefinition. In [3] and [4], a theory of contractis presented that addresses the problem of composition ofmultiple services. The correctness for service compositionsis modeled using process calculi and the notions of strongservice compliance and strong subcontract pre-order are in-vestigated.For REST architectural style, Zou et. al [21] propose an

Accountable State Transfer(AST) architecture to bridge theaccountability gap in REST. The approach uses service con-tract as foundation for enabling accountability. The paperoutlines the architectural decisions and principles for en-abling accountability, followed by AST architecture with ac-countable state transfer protocol. The service contracts areimplemented as an ontology and the service executions arestored in a knowledge base to allow reasoning between dif-ferent concepts of a contract.In the context of modeling behavioral specifications and

using contracts with UML, Lohmann et. al [14, 10]. usevisual contracts to specify the dynamic behavior and classdiagrams to specify the static aspect of a web service. Graphtransformations are annotated on to the class diagram withobject diagrams specifying pre- and post-conditions of theoperations.We consider that the main strength of our approach is

that our models lead to RESTful web services. In addition,we can generate implementation stubs and behaviorally en-riched interfaces from models that have many applications.The use of UML protocol state machine for modeling pro-vides behaviorally enriched interfaces that show the sequenceof operations that can be invoked on the service, the condi-tions under which they can be invoked and the expectedresults. Both the conceptual and behavioral models serve asspecification document. Also, contracts can be directly gen-

1604

erated from these models and asserted into syntactic servicedescriptions as shown in Section 4 and 5.

9. CONCLUSION AND FUTURE WORKIn this article, we present a novel approach to model the

behavioral interface of a RESTful web service. A concep-tual resource model shows different resources and how canthey be addressed. The behavioral model specifies how theservice should be used by showing the order of method invo-cations and the conditions on these methods. We have usedUML class and protocol state machine diagrams to modelthe conceptual and behavioral aspects of the web service.The models can be used to generate a contract in the formof preconditions and postconditions for methods of an inter-face. These contracts can be included in a WADL interfacespecification. The resulting service is RESTful by construc-tion.

The behavioral RESTful interfaces have many applica-tions. They can serve as documentation for existing ser-vices or as a blue print for developing new ones. The modelscan be used to generate implementation stubs in commonlyused web frameworks like Django and Ruby on Rails. Theycan also be used to monitor the interaction between a ser-vice and its clients and warn if any of the parties breachesthe interface contract. The generation of tests from inter-face contracts is also a promising application of formalizedbehavioral interfaces.

In the context of web services, our work is novel as weprovide a modeling approach for a RESTful web service thatcaptures both the static and behavioral features of an inter-face. The models exhibit all attributes of REST web servicesand are easy to understand and communicate.

We are currently working on extending our approach tosupport modeling interfaces for composite RESTful web ser-vices and provide a complete modeling approach that alsocaters the process of RESTful web service composition.

10. REFERENCES[1] X. Bai, Y. Wang, G. Dai, W. T. Tsai, and Y. Chen. A

Framework for Contract-Based CollaborativeVerification and Validation of Web Services. LectureNotes in Computer Science, 4608:258–273, 2007.

[2] A. Bertolino and A. Polini. The audition frameworkfor testing web services interoperability. Proceedings of31th Euromicro Conference on Software Engineeringand advanced Applications, pages 134–142, 2005.

[3] M. Bravetti and G. Zavattaro. A Theory of StrongService Compliance. Proceedings of the 9thinternational conference on Coordination models andlanguages, pages 96–112, 2007.

[4] M. Bravetti and G. Zavattaro. A Foundational Theoryof Contracts for Multi-party Service Composition.Fundamentals of Software Engineering 2007: SelectedContributions, 89:451–478, 2009.

[5] L. C. Briand, Y. Labiche, and H. Sun. Investigatingthe Use of Analysis Contracts to Support FaultIsolation in Object Oriented Code. Proceedings of the2002 ACM SIGSOFT International Symposium onSoftware testing and analysis, pages 70–80, 2002.

[6] G. Castagna, N. Gesbert, and L. Padovani. A Theoryof Contracts for Web Services. Proceedings of ACM

Transactions on Programming Languages and Systems(TOPLAS), 31, 2009.

[7] I. Ciupa and A. Leitner. Automatic testing based onDesign by Contract. Proceedings of Net.ObjectDaysS05, 6th Annual International Conference onObject-Oriented and Internet-based Technologies,Concepts and Applications for a Networked World,pages 545–557, 2005.

[8] G. Dai, X. Bai, Y. Wang, and F. Dai. Contract-BasedTesting for Web Services. Proceedings of 31st AnnualInternational Computer Software and ApplicationsConference, pages 517–526, 2007.

[9] M. J. Hadley. WADL specifications. 2006.http://www.w3.org/Submission/wadl/.

[10] J. H. Hausmann, R. Heckel, and M. Lohmann.Model-based development of Web service descriptionsenabling a precise matching concept. In InternationalJournal of Web Services Research, 2:67–85, 2005.

[11] M. Laitkorpi, J. Koskinen, and T. Systa. AUML-based Approach for Abstracting ApplicationInterfaces to REST-like Services. Proceedings of the13th Working Conference on Reverse Engineering,pages 134–146, 2006.

[12] M. Laitkorpi, P. Selonen, and T. Systa. Towards aModel Driven Process fo Designing ResTful WebServices. To appear: International Conference on WebServices, 2009.

[13] A. Leitner, I. Ciupa, O. Manuel, B. Meyer, andA. Fiva. Contract driven development = test drivendevelopment-writing test cases. Proceedings of theACM Symposium on The Foundations of SoftwareEngineering, pages 425–434, 2007.

[14] M. Lohmann, L. Mariani, and R. Heckel. AModel-driven Approach to Discovery, Testing, andMonitoring of Web Services. In L. Baresi, E. Di Nitto(eds.): Test and Analysis of Web Services, pages173–204, 2007.

[15] B. Meyer. Applying Design by Contract. Computer,IEEE Computer, 25:40–51, 1992.

[16] I. Porres and I. Rauf. From uml protocolstatemachines to class contracts. Procceedings of theInternational Conference on Software Test,Verification and Validation(ICST 2010), 2010.

[17] I. Rauf, M. Iqbal, and Z.I. Malik. UML BasedModeling of Web Service Composition-A Survey.Proceedings of the 2008 Sixth International Conferenceon Software Engineering Research, Management andApplications, pages 301–307, 2008.

[18] L. Richardson and S. Ruby. RESTful Web Services.O’Reilly, 2007.

[19] M. Siikarla, M. Laitkorpi, P. Selonen, and T. Systa.Transformations have to be developed ReST assured.Proceedings of the 1st international conference onTheory and Practice of Model Transformations, 2008.

[20] OMG UML. 2.2 Superstructure Specification. OMGed, 2009. http://www.omg.org/spec/UML/2.2/.

[21] J. Zou, J. Mei, and Y. Wang. From RepresentationState Transfer to Accountable State TransferArchitecture. Proceedings of 2010 IEEE InternationalConference on Web Services, pages 99–306, 2010.

1605