To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
The short answer is, use it whenever you can! But of course, things really aren't that simple.
If you are designing and developing a new, highly scalable Web application, the REST approach is without question the best way to go. If you are working on an extension to an existing enterprise application, however, or on an integration project relying in whole or in part on existing infrastructure, the decision is a bit tougher. Ultimately, because of where we are as an industry, and how we got here, the REST approach is much more compelling if you are designing and developing a new Web application than if you are reusing an existing application.
But before we get too far with this discussion, it's important to point out a distinction between REST as an architectural style, which can be implemented using any technology, and REST/HTTP as an implementation of the REST architecture. REST/HTTP is probably what most people mean when referring to REST informally, but I want to be clear about it (for that reason, we use REST/HTTP when discussing scalable Web servers in the second edition of "Principles of Transaction Processing," due out in June).
In general, IT systems have been designed for automating internal business operations. At least until the Web came along. And then IT systems also started to be designed for access from Web browsers external to a business's operations.
At the High Performance Transaction Processing (HPTS) conference in October of 2007 the presenters represented all the large scale Web sites (Google, eBay, PayPal, SecondLife, SalesForce, etc.) while the audience represented the inventors and developers of TP monitors, application servers, and relational database products. The Web guys told the database and TP guys that the products most businesses have been using for 30 years or so just didn't meet their requirements, and they have had to develop custom solutions to successfully use REST/HTTP. The requirements of the large Web sites for using REST/HTTP are sufficiently different from the requirements of internal IT systems that traditional software products do not meet them very well.
The success of the large Web sites certainly proves the capability of the REST architectural style and its implementation in HTTP. But it also clearly indicates the inadequacies in the current generation of software products and points out where the innovation in large scale distributed computing systems is going to be coming from. New product designs will be emerging from this space over the next several years, and in fact this is already starting to happen with the new generation of cache management products.
Unfortunately, when you look for common patterns among the Web site infrastructures, they aren't yet there. Everyone is doing something different. This means it will take some time for the established "new way" of doing big applications to emerge, and for the next generation of products to emerge as well.
I also clearly remember a TeleManagement Forum keynote a couple of years ago extolling the virtues of Web based business models (self service, low cost of communications, easier development etc.) but ending with the common complaint of established telecommunications corporations who find it very challenging to do business on the Web because of their "antediluvian back office systems."
So there you have the dilemma in a nutshell. The Web technologies and the REST/HTTP approach are proven to work well in the largest, most demanding environments and offer significant benefits. However, if you have an existing system that was not designed for the Web, you have an architectural mismatch that may require significant investment to overcome.
In some cases, the investment will be within reason, or justified by the benefits. In other cases, it will be more cost effective and beneficial to the business to extend and reuse existing infrastructures. In other cases, a hybrid or partial adoption of REST/HTTP may be a good way to go.
But until enough common patterns emerge from the world of the scalable Web - and they are starting to - the REST/HTTP approach is going to require a lot of custom code for the equivalent of features and functions you can buy out of the box with existing enterprise software products. While the benefits of adopting REST/HTTP are clear, but the cost/benefit picture of doing so is not always so clear.
|
