29-08-2014, 02:52 PM
RESTful Web services
RESTful.doc (Size: 65.5 KB / Downloads: 15)
Abstract
A Web service is a Web page that is meant to be consumed by an autonomous program. Web service requires an architectural style to make sense of them as there need not be a human being on the receiver end to make sense of them. REST (REpresentational State Transfer) represents the model of how the modern Web should work. It is an architectural pattern that distills the way the Web already works. REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.
By its nature, user actions within a distributed hypermedia system require the transfer of large amounts of data from where the data is stored to where it is used. Thus, the Web architecture must be designed for large-grain data transfer. The architecture needs to minimize the latency as much as possible. It must be scalable, secure and capable of encapsulate legacy and new elements well, as Web is subjected to constant change. REST provides a set of architectural constraints that, when applied as a whole, address all above said issues.
Introduction
A Web service is a Web page that is meant to be consumed by an autonomous program. Web
Service requires an architectural style to make sense of them as there need not be a human being on the receiver end to make sense of them.REST (Representational State Transfer) represents the model of how the modern Web should Work. It is an architectural pattern that distills the way the Web already works.
REST provides a set of architectural constraints that, when applied as a whole, emphasizes
Scalability of component interactions, generality of interfaces, independent deployment of
Components, and intermediary components to reduce interaction late ncy, enforce security, and
Encapsulate legacy systems.
Advantages
•Scalable component interactions
•General interfaces
•Independently deployed connectors.
•Reduced interaction latency.
•Strengthened security.
•Safe encapsulation of legacy systems.
•Supports intermediaries (proxies and gateways) as data transformation and caching
components.
•Separates server implementation from the client’s perception of resources (“Cool URIs
Don’t Change”).
•Scales well to large numbers of clients.
•Enables transfer of data in streams of unlimited size and type.
Disadvantages
•It sacrifices some of the advantages of other architectures.
•Stateful interaction with an FTP site.
•It retains a single interface for everything
•The stateless constraint reflects a design trade-off. The disadvantage is that it may
decrease network performance by increasing the repetitive data (per-interaction
overhead) sent in a series of requests, since that data cannot be left on the server in a
shared context. In addition, placing the application state on the client-side reduces the
server’s control over consistent application behavior, since the application becomes
dependent on the correct implementation of semantics across multiple client versions.
Conclusion
Service-Oriented Architecture can be implemented in different ways. General focus is on whatever architecture gets the job done. SOAP and REST have their strengths and weaknesses and will be highly suitable to some applications and positively terrible for others. The decision of which to use depends entirely on the circumstances of the application.