White Paper
REST:
REST is a framework built on the principle of today's World Wide Web. Yes, it uses the principles of WWW in a way it is a challenge to lay down a new architecture that is already widely deployed and same time makes sure that it won't adversely impact or destroy the very principles on which WWW was Architecture and built and needless to say which laid path for WWW to succeed. WWW principles are simple and stubborn in the way it withholds lot of architectures built on this for many years, for example Web Services, which uses the simple WWW principles by piggy backing their own architecture on WWW.
This paper discusses the way REST is implemented and the difference between a traditional Web Services vs. Rest based Web Services, and also gives an oversight of the architecture and the need for this in the real world. This paper eventually will enable user to consider REST as one of the possible choices while designing solutions for the Web.
Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. The terms “Representational State Transfer” and “REST” were introduced and defined in 2000 by the doctoral dissertation of Roy Fielding. [1] [2]. One of the principal authors of the Hypertext Transfer Protocol (HTTP) specification versions 1.0 and 1.1. Systems which follow REST principles are often referred to as “RESTful” (Excerpts from Wikipedia).
REST is an architectural style that treats the Web as a resource-centric application. Practically, this means each URL in a RESTful application represents a resource. Traditional Web Applications access resources using HTTP GET or POST operations. In Contrast, RESTful application access resources following the create, read, update, and delete (CRUD) style using the full range of HTTP verbs (POST, GET, PUT and DELETE). As HTTP is a stateless so is REST.
For more details: Download
Bridging the Gap :
Key Points:
- It is not uncommon that a software investment does not meet all your needs because your requirements have changed since the system was selected
- Most companies' research and find the best system available that meets their core business needs and then create the rest
- Sometimes the limitations of an investment are not clear in the beginning. Other times the problem arises because senior management has a different focus than the day-to-day line managers or sales managers
- Additionally, the industry changes so quickly, including new regulations, that it is hard to buy all the software and technology that you will want 12 months in the future
For more details: Download
Platform Reusability to Support Multiple State Agencies, Systems and Programs
About
In the current, ever-changing state agency technology environment, state CIOs is being asked to provide systems interoperability between existing, deployed platforms with newly required services and their associated future platforms. Strategic planning is ongoing regarding upgrades of legacy platforms, deployment of new platforms, and the sharing of platforms within agencies, with other agencies, and with other states to support the interoperable exchange of disparate data, systems, and services. Decisions must be made as to how to upgrade and align the legacy platforms with new business requirements and agency objectives.
Reusability:
Reusability can be defined as the ability to use existing functionality without having to replicate or modify this functionality for another environment. Reusability should not be confused with reproducibility, which allows for replication of functionality in another environment. Rather, reusability allows for a functional (such as a web service) to be published by one platform and then natively consumed by other, disparate platforms, thereby achieving multiple business objectives and goals. A core function of the reusable platform is the ability to offer components that can be leveraged across multiple implementations.
For more details: Download
