Analyzing Consistency of Behavioral REST Web Service Interfaces

REST web services can offer complex operations that do more than just simply creating, retrieving, updating and deleting information from a database. We have proposed an approach to design the interfaces of behavioral REST web services by defining a resource and a behavioral model using UML. In this paper we discuss the consistency between the resource and behavioral models that represent service states using state invariants. The state invariants are defined as predicates over resources and describe what are the valid state configurations of a behavioral model. If a state invariant is unsatisfiable then there is no valid state configuration containing the state and there is no service that can implement the service interface. We also show how we can use reasoning tools to determine the consistency between these design models.

💡 Research Summary

The paper addresses the problem of ensuring consistency between design models of behavioral RESTful web service interfaces. The authors propose a model‑driven approach in which a service is described by two UML diagrams: a resource model (class diagram) and a behavioral model (protocol state machine). The resource model captures the static structure of the service – collections, normal resources, attributes, and associations – and enforces REST constraints such as connectivity (every resource reachable from a designated root) and addressability (unique association names yielding deterministic URIs). The behavioral model captures the dynamic lifecycle: states represent particular configurations of resources, transitions are triggered by HTTP methods (GET, PUT, POST, DELETE), and each state is annotated with a state invariant – a logical predicate over resource attributes that must hold for the state to be active.

Consistency is defined semantically: the set of possible resource configurations (ΔI) is interpreted as a domain; each resource definition and each state corresponds to a subset of ΔI, and UML constructs (generalization, associations, state hierarchy, invariants) are translated into set‑theoretic constraints. The overall design is consistent iff the conjunction of all constraints is satisfiable – i.e., there exists at least one concrete configuration that simultaneously satisfies the resource structure and all state invariants. If the constraints are unsatisfiable, some state cannot ever be reached or some resource definition cannot be instantiated, indicating a design error.

To automate the satisfiability check, the authors map the UML models into an OWL 2 DL ontology, leveraging Description Logic (DL) reasoning. Classes become OWL classes, attributes become data properties, associations become object properties, and state invariants become class axioms (e.g., intersections, equivalences). The resulting ontology is fed to an OWL 2 reasoner (such as HermiT or Pellet). The reasoner reports unsatisfiable concepts, which directly point to inconsistent resource definitions or unreachable states. The paper also describes a prototype tool that generates a Django‑based skeleton (models.py, urls.py, views.py) from the UML models, allowing developers to fill in business logic while preserving the verified design.

A running example of a hotel‑booking service illustrates the approach. The service includes resources like Booking, Room, Payment, and Cancellation, with a state machine that models creation, payment processing, confirmation, cancellation, and deletion. By deliberately altering a state invariant (e.g., setting payment.waiting = false while still in a processing‑payment state), the authors create a conflict that the reasoner detects as unsatisfiable, demonstrating the practical utility of the method.

Key contributions include: (1) a formal definition of RESTful resource and behavioral models with precise REST constraints; (2) a mapping of UML constructs and state invariants to DL axioms; (3) an automated consistency checking pipeline using OWL 2 reasoning; (4) a code‑generation prototype that bridges verified models to executable service skeletons. The approach enables early detection of design flaws, reduces costly runtime errors, and supports the development of complex, stateful REST services. Limitations are acknowledged: the method currently handles only the subset of UML state machines expressible in OWL 2 DL, and more sophisticated features such as history states or concurrency control may require richer formalisms. Nonetheless, the work demonstrates that model‑based design combined with automated reasoning can substantially improve the reliability of RESTful web service specifications.