In a blog post, Joe Gregorio, well-known blogger and author of the excellent XML.com series on REST, shows how to apply REST design principles to a complex application -- the Apache DayTrader benchmark.
DayTrader, originally developed by IBM as the Trade Performance Benchmark Sample, is an example online stock trading application that was donated to the Apache Geronimo community in 2005. The application supports use cases such as login, view portfolio, lookup stock quotes, and buy or sell stock shares.
The article shows how to map the business operations supported by DayTrader to resources, each identified by its own URI and supporting the uniform HTTP interface. While the core functionality maps to a REST model quite naturally (roughly 20 operations end up being mapped to 5 "collection resources"), some more work is required to support reliable delivery of orders.
To support this, Joe introduces a pending_orders collection, where orders are first created via POST and then invidually updated using PUT. As the PUT operation is idempotent, it can be retried if the result is unclear without causing unwanted effects (in this case, submitting the same order twice).
This method to support reliability is not standardized -- at least not beyond the level provided by HTTP. In addition to the ad-hoc solution introduced in the posting, Joe references HTTPLR, a proposal by Bill de hÓra, Mark Nottingham's POE (POST Once Exactly) and Paul Prescod's Reliable Delivery in HTTP. (Another entry worth pointing to is Yaron Goland's SOA-Rity).
The posting concludes:
DayTrader, originally developed by IBM as the Trade Performance Benchmark Sample, is an example online stock trading application that was donated to the Apache Geronimo community in 2005. The application supports use cases such as login, view portfolio, lookup stock quotes, and buy or sell stock shares.
The article shows how to map the business operations supported by DayTrader to resources, each identified by its own URI and supporting the uniform HTTP interface. While the core functionality maps to a REST model quite naturally (roughly 20 operations end up being mapped to 5 "collection resources"), some more work is required to support reliable delivery of orders.
To support this, Joe introduces a pending_orders collection, where orders are first created via POST and then invidually updated using PUT. As the PUT operation is idempotent, it can be retried if the result is unclear without causing unwanted effects (in this case, submitting the same order twice).
This method to support reliability is not standardized -- at least not beyond the level provided by HTTP. In addition to the ad-hoc solution introduced in the posting, Joe references HTTPLR, a proposal by Bill de hÓra, Mark Nottingham's POE (POST Once Exactly) and Paul Prescod's Reliable Delivery in HTTP. (Another entry worth pointing to is Yaron Goland's SOA-Rity).
The posting concludes:
Hopefullly what you will take away from this example is not the explicit utility of building a RESTful interface to DayTrader, but that REST can be applied to complex scenarios, that the collection model can make such modelling easier, and that HTTP does offer mechanisms for reliability. I hope it goes without saying that now that you have a RESTful interface you can start taking advantage of other HTTP mechanisms like caching, etags, and gzip.