Posted on by & filed under Content - Highlights and Reviews, Programming & Development.

Web applications and systems are hard to write. They start off simple, but as time goes on and features are added or changed, they can become complicated. Adhering to RESTful practices can help simplify those systems by focusing on the state of your applications.

It’s possible to bolt a RESTful service onto a system that does not focus on state, but REST can be much easier, and more useful if designed into the system from the start. Read 8.4. State and Statelessness in RESTful Web Services to learn more about state in REST.

When you’re starting out in REST, one of the hardest things to do is to leave behind the mentality of the command pattern.

If you think of an online ordering system, and an Order, the user typically issues commands to move through the various order stages:

  • Start Order
  • Confirm Order
  • Choose delivery address
  • Confirm Payment

These are very command based terms, and can often result in command based services.

These URI’s might be backed by an order class, and an order service, which looks something like the following:

That example is a little trite, but systems do exist that in effect let commands in the form of a URI dictate how an ordering process works. Thinking a little about state can help you move from a command-based model, to a state-based model.

In the example below, there is a single update method on the orders service, which handles the state transition, including the automatic validation state transition:

Using state also allows consumers of your services to understand more about your API.
You can easily return the next valid state, because now the order understands state in a more uniform fashion when retrieving an order.

Take this example, where we are not embracing state:

The state transition is much more unwieldy, and involves lots of logic and if/else statements in order to manage the order state. By pushing the state of an order into the Order class itself, we can simplify the code, and make the orders service handle any state. Whenever an order is loaded, the state is pushed to the client, whatever state the order is in:

When writing RESTful systems, it’s important to remember that being RESTful is not just about having URIs that look RESTful, or having controllers or services that respond to the HTTP verbs GET, POST, PUT, DELETE. It’s instead about pushing that mindset into your application.

While it’s possible to layer a RESTful API or service layer on top of an application that has not embraced REST, that application will not leverage the benefits gained by embracing state.

Given that the examples above are a little trite, it might not be immediately visible how to handle more complex operations, based upon state. So, for example, when an order moves to a ‘Confirmed‘ state, you may wish to fire some events that inform the packing department, in our example, to begin picking and packing the order.

A common pattern that goes hand in hand with state-based systems are domain events.

In our Order class, we fire an event:

We then have a handler, or subscriber to our events:

I won’t go into the details of how to wire up domain event publishers and subscribers in this post, but there are lots of open source implementations of event sourcing. When the Order domain class notifies its registered handlers about a change in order state, the handler receives a notification, and tells the packing department in our example to prepare the order.

Domain events are a nice way to separate the state of your application. Using them, you can have as many subscribers as you wish, without breaking single responsibility (but this is another topic!).

For more details about REST, see the ebooks referenced below.

Safari Books Online has the content you need

REST continues to gain momentum as the best method for building web services, leaving many web architects to consider whether and how to include this approach in their SOA and SOAP-dominated world. Rest in Practice offers a down-to-earth explanation of REST, with techniques and examples that show you how to design and implement integration solutions using the REST architectural style.
The basic rules of REST APIs – “many nouns, few verbs, stick with HTTP” – seem easy, but that simplicity and power require discipline to work smoothly. REST API Design Rulebook provides the next steps for implementing complex REST projects on simple and extensible foundations.
SOA with REST: Principles, Patterns & Constraints for Building Enterprise Solutions with REST is the first comprehensive tutorial and reference for designing and building RESTful services as part of service-oriented solutions and in conjunction with service-oriented architecture (SOA). This book demonstrates that REST is not only a suitable medium for building truly service-oriented solutions, but also that the service-oriented architectural model is a necessary foundation for REST technology architectures to realize their full business potential.

About the author

Ben Keeping is a freelance developer based in the UK. He currently specializes in applications written in .NET and Ruby, using lean and agile techniques. He can be contacted @benkeeping.

Tags: REST, RESTful Practices, State, state-based model, System Design,

Comments are closed.