A RESTful interface expects that the user that calls the RESTful service will maintain process state, where stateful behavior is needed for multistage transactions. This can place a burden on the application or user side, especially if browser-based access is needed.
Cloud architects should explore REST-friendly rather than REST architecture models for state control. Transitioning and sustaining RESTful model costs should be looked into in addition to the impact of state control on workflow and cloud effectiveness.
The concept of state is important to most online applications because the information needed to complete an activity may require several iterations. State information has to be maintained in successive posts to be applied accurately. An update usually consists of the following:
- Requesting data as the first state
- Displaying and updating data by the user or client as the second state
- Executing the update through the application and DBMS as the third state
- Displaying final results
A good point to start a state control discussion is the difference between REST-friendly and REST architecture. RESTful state control, strictly applied, means the caller or client maintains state. REST-friendly means the underlying resource can manage state on behalf of the client. The two are different not only in technology, but also in how they present recovery or auditability options.
When a client maintains state, it may be difficult to determine the state of a multi-phase transaction by inspecting the resource side of the relationship. Particularly for mobile clients, connection loss can complicate insuring transaction and database integrity. Users report that recovery and auditing of transaction completeness are the biggest reasons to avoid client-maintained-state models.
Alternative models for controlling state
Three models dominate the field for controlling state: back-end state control, use of a Web front-end to a stateful flow, and logic-embedded state management. All three can preserve a RESTful interface and reliable control state.
Back-end state control means that every client activity, when initiated, generates a context record to represent the dialog. This record contains any information generated by the dialog and the dialog's state. When a new REST call is made, the context record associated with the calling device or application is restored and the input is processed according to that context. If a multi-stage dialog is abandoned in an incomplete state, the context record can be used to restore information or databases to their base state.
Back-end control often requires an application redesign. The opposite extreme is the simple Web front-end. Here, the client device exercises a RESTful interface with an intermediary Web server that manages the relationship with the application. The server-side application can maintain state on behalf of the client. If done properly, there will be enough information available in the Web server to back out incomplete transactions. This approach is good to use when it's necessary to adapt existing SOA or stateful components to REST.
The third option is to build state control implicitly into application logic by analyzing information provided by the client. This completeness check dispatches screens based on what's missing and posts the transaction when required data is available. This approach expects all the data to be provided by the RESTful API and will continue to return an indication of incomplete information until it's filled in.
Some businesses like this model because it adapts the client interface to the state of the data itself, a more rational model than a state variable that could be set incorrectly. It can also be applied at the Web front-end so it can be used as a refinement of the second approach.
Logic approach may trump others
The logic-based approach is also a derivative of a modern data-driven process or application steering work or events. Many event-driven systems are adopting an application model where events are steered through a state/event or data/process model based on a table or policy set. This is valuable in applications where information that drives activity or transactions can originate from many sources, such as traditional devices, M2M sensors and other applications. All activity is reduced to a set of events that can easily be represented as RESTful APIs.
Ultimately, a logic-based process of state control tends to encourage componentization down to the level of data elements. This facilitates processing updates to any element as a discrete event. Low-level componentization can encourage Agile development and improve component reuse but risks high workflow overheads.
Given that logic-based state control may be intrinsic, or at least related, to M2M and the Internet of Things, it's wise to consider means of managing workflow delays and their impact on QoE. Otherwise a promising avenue of development could be closed off.
It's always a risk to consider any approach to RESTful state control as a preferred strategy. For those with current applications to adapt, it's almost certain a simple front-end-based state control process will require the least amount of time and money. Back-end control of state is popular where component load-sharing is used because the back-end context record, if restored by any component image, will drive correct processing of REST API calls.
Despite the popularity of other approaches, there are many forces pushing state control toward the last model, not the least of which is the evolution of applications to contextual analysis of user or worker location, presence, etc. All of these can change quickly and are asynchronous to the traditional client or server dialog that simple state-driven processes support. Since it's difficult to manage sharing of components and Agile or dynamic development where different state control mechanisms are used, it may be that the logic or data-driven model will prevail.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
More on REST architecture