Beruflich Dokumente
Kultur Dokumente
INTRODUCTION
REST stands for REpresentational State Transfer and it is a new architectural approach for large-scale software design of web services, which was coined by Roy Fielding in his Ph.D Dissertation to describe the architectural style of networked systems [3]. From the pure definition, we see that REST is an architectural style, not a standard, protocol or a solution. REST is an architectural style defining the principles of distributed networked systems. The motivation for developing REST was to create an architectural model for how the Web should work, such that it could serve as the guiding framework for the web protocol standards. REST has been applied to describe the desired Web architecture, help identify existing problems, compare alternative solutions, and ensure that protocol extensions would not violate the core constraints that make the Web successful.
On the other hand, the REST also provides a set of architectural constraints when applied as a whole. REST emphasizes the component scalabilities, uniform interfaces, securities, independent deployments and so forth. In the later section, I will introduce the characters of REST.
2. LITERATURE SURVEY
2.1. The researcher discusses about the RESTful web services and also discusses the characteristics. The author says that the designer of REST Web services start with the system needs as a whole, without constraints, and incrementally identifies and applies constraints to elements of the system in order to differentiate the design space and allow the forces that influence system behaviour to flow naturally, in harmony with the system. In the paper the author discusses about the incremental way of developing a general RESTful webservice. [3].
2.2. The author discusses the various characteristics of RESTful webservices . The architectural design provides a set of architectural constraints, it emphasizes scalability of component interactions, generality of interfaces, and independent deployment of components, intermediary components to reduce interaction latency, enforce security and encapsulate legacy systems. Subsequently these characteristics are being used to guide the evolution of the Web. [6].
2.3. The author discusses and outlines the main difference between REST and Web Services (WS). According to the author the main difference is that REST promotes and recommends generic operations on resources, while WS does not provide generic operations. There are some other differences in the aspects of security, WS entity and identifiers. [6]. The author broadly differentiates between the REST with SOAP on various parameters.
2.4.The author discusses about the various key principles that are to be followed while developing a RESTful webservice. Some of the key principles that he talks about are Identification of resources ,Manipulation of resources through representations ,Selfdescriptive messages , Hypermedia as the engine of application state Resource Addressability ,Resource Discovery [7].
2.5. The author discusses about the various architectural ways of developing a RESTful webservice .The set of architectural properties of software architecture includes all properties that derive from the selection and arrangement of components, connectors, and data within the system.[9] Examples include both the functional properties achieved by the system and non-functional properties, such as relative ease of evolution, reusability of components, efficiency, and dynamic extensibility, often referred to as quality attributes [8].
3.1.2.Stateless: each request from client to server must contain all the information
necessary to understand the request, and cannot take advantage of any stored context on the server.
3.1.4.Uniform interface: all resources are accessed with a generic interface (e.g., HTTP
GET, POST, PUT, and DELETE).
3.1.5.Named resources: the system is comprised of resources, which are named using a
URL.
Only the 1 generation uses the HTTP Post Uses SOAP enveloping to identify the desired procedure to be invoked Security in SOAP requires additional infrastructure in Web to enable message transport level security concerns Every entity is centred around interfaces and messages that are channelled into the interface A good approach for closed systems No caching capabilities Manipulation of data is based on the message internal structure and application protocols An RPC/Document oriented architectures
WRDL provides the description to the web WSDL provides the description to services resource interfaces which can receive and deliver SOAP Messages
First generation web services are like first generation Internet connections. They are not integrated with each other and are not designed so that third parties can easily integrate them in a uniform way. Some web services specialists believe that the next generation will be more like the integrated Web that arose for online publishing and human-computer interactions. And the second generation web services will actually build much more heavily on the architecture that made the Web work, using the holy trinity: standardized formats, a standardized application protocol, and a single URI namespace. REST is underlying architectural model of the current Web, and it explains why the Web has URIs, HTTP, HTML, JavaScript, and many other features. The main difference between REST and Web Services (WS) is that REST promotes and recommends generic operations on resources, while WS does not provide generic operations. There are some other differences in the 5
aspects of security, WS entity and identifiers. Table 1 gives a general overview of the comparisons between REST and WS [6].
3.2.1.1 . Addressing
Table 2. Addressing REST - REST architectures utilize the existing web addressing model - Standardized URI schemes subsume protocols - Standardized distributed naming authorities (DNS) - Standardized way of discovering, referring to resources SOAP - SOAP applications define their own addressing schemes - Web service entry-points have URIs - Resources have custom, service-specific addresses - No standardized way of discovering, referring to resources
identified resources SOAP - SOAP does not provide for generic operations - Each application defines its own set of operations - Creates need for description, discovery mechanisms - Knowledge of semantics of operation is out-of-band
3.2.1.4. Standards
REST is not a standard; it is only a structural style. However, REST prescribes the uses of the standards, such as HTTP, URL, XML/HTML/GIF/JPEG, text/xml, text/html, image/gif, image/jpeg and so forth. REST promises to make Web services available using the existing Internet standards [3]. While SOAP is an XML based protocol, and the SOAP based approach involves a range of emerging standards, but not all of which will be adopted.
3.2.1.5. ToolKits
Many application tool vendors are building SOAP based products, aimed at making the development and deployment of Web services as easy as any other kind of application development. While many development tools support REST, such as HTTP and XML, but commercial REST tools do not exist. 7
3.2.1.7. Security
REST proponents say that using the SOAP protocol to access the functions of remote programs directly is doomed to suffer from the same type of interoperability problems that hobbled previous distributed computing architectures. The security problem which plaque SOAP is firewalls do not understand the meaning of SOAP based Web services messages, they never let those messages pass. REST messages do not have this problem, because they only use operations specified in the HTTP standard, where operations are well understood by firewall applications and administrators. REST advocates say their way of doing Web services is more secure because of its reliance on the Internets existing security infrastructure. The SOAP security is still developing, but it promises to give administrators greater control over who accesses Web services and what rights those users have. Though REST takes some advantages, REST is not the best solution for every Web service. Data that needs to be secure should not be sent as parameters in URIs. And large amounts of data, like that in detailed purchase orders can quickly become cumbersome or even out of bounds within a URI. In these cases, SOAP is indeed a solid solution. However, it is important to try REST first and resort to SOAP only when necessary. This helps to keep application development simple and accessible. The REST philosophy is catching on with developers of Web services. Developers need to understand that sending and receiving a SOAP message is not always the best way for applications to communicate. Sometimes, a simple REST interface and a plain text response save time and resources in the process.
components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems. REST is a hybrid style derived from several of the network-based architectural styles and combined with additional constraints that define a uniform connector interface [3]. The design rationale behind the Web architecture can be described by an architectural style consisting of the set of constraints applied to elements within the architecture. This chapter is going to provide a general overview of REST by going through the process of deriving it as an architectural style.
10
relative importance of the various architectural properties depends on the nature of the intended system. The purpose of REST architectural properties is to differentiate and classify the architectural styles. The REST properties include: performance, scalability, simplicity, modifiability, visibility, portability and reliability.
Figure 1. Data-Flow Styles The advantages of PF are that PF allows the designer to understand the overall input/output of the system as a simple composition of the behaviours of the individual filters (simplicity). Second, PF supports reuse: any two filters can be hooked together, provided they agree on the data that is being transmitted between them (reusability). Third, PF systems can be easily maintained and enhanced: new filters can be added to existing system (extensibility) and old filters can be replaced by improved ones (evolvability). Fourth, they permit certain 11
kinds of specialized analysis (verifiability), such as throughput and deadlock analysis. Finally, they naturally support concurrent execution (user-perceived performance). Disadvantages of the PF style include: propagation delay is added through long pipelines, batch sequential processing occurs if a filter cannot incrementally process its inputs, and no interactivity is allowed. A filter cannot interact with its environment because it cannot know that any particular output stream shares a controller with any particular input stream. These properties decrease user-perceived performance if the problem being addressed does not fit the pattern of a data flow stream. [3]
Figure 2. Replication Styles The primary advantage of PP is improved user-perceived performance, both by reducing the latency of normal requests and enabling disconnected operation in the face of primary server failure or intentional roaming off the network [3]. Simplicity remains neutral, since the complexity of replication is offset by the savings of allowing network-unaware components to operate transparently on locally replicated data. Maintaining consistency is the primary concern.
12
This section is describes the applications from applying REST architectural style while authoring the Internet standards for HTTP and URI .
3.5.1.1. Extensibility
HTTP was modified to support the gradual and fragmented deployment of changes within an already deployed architecture through the introduction of versioning the requirements and rules for extending each of the protocols syntax elements. As we know, HTTP is a collection of protocols, and the major and minor version numbers that share the same name primary are used to distinguish these protocols. The reason is because they correspond to the protocol expected when communicating directly with a service based on the http URL namespace. A connector must obey the constraints placed on the HTTP version protocol element included in each message. A number of separate namespaces are included in HTTP, each of these namespaces has different constraints, but these entire share the requirement of being extensible without bound. Some of the namespaces are governed by separate Internet standards and shared by multiple protocols, while others are governed by HTTP, including the namespaces for method names, response status codes, non-MIME header field names, and values within standard HTTP header fields. Early HTTP did not define a consistent set of rules for how changes within these namespaces could be deployed; this was one of the first problems tackled by the specification effort. While, this deployment problem has been fixed by separating the rules for parsing and forwarding HTTP messages from the semantics associated with new HTTP protocol elements. [3]
14
4. CONCLUSION
The seminar report introduces the REST REpresentational State Transfer, Dr. Roy Fielding firstly coined this in his Ph.D dissertation. REST is a coordinated set of architectural constraints that attempts to minimize latency and network communication while at the same time maximizing the independence and scalability of component implementations. This is achieved by placing constraints on connector semantics where other styles have focused on component semantics. REST enables the caching and reuse of interactions, dynamic substitutability of components, and processing of actions by intermediaries, thereby meeting the needs of an Internet-scale distributed hypermedia system. The report mainly used Fieldings dissertation and Chahdes lecture slides as references. The contents covered the definitions, background, and importance of REST in the Introduction section, aiming to give the reader a general understand of REST. Next, I presented the RESTs characteristics and the comparisons with other web services, and the key principles of REST, which aims to make people having a deeper understanding of REST and its significance. Step by step, the REST architectural style and its application to HTTP and URI were presented in the last two sections. From my point of view, I think we should basically understand the following aspects after reading the report: REST is neither a standard nor a protocol, it is an architectural style of web services. The goal of the paper is to know that the modern Web is one instance of REST architecture style and how to utilize the characteristics, principles and properties of REST to make the web successful. Additionally, we should also know REST is different from SOAP, though people always make comparisons between them. REST is an architectural style, while SOAP is a protocol. For future work, it will focus on extending the architectural guidance toward the development of a replacement for the HTTP protocol family. There has also been some interest in extending REST to consider variable request priorities, differentiated quality-ofservice, and representations consisting of continuous data streams, such as those generated by broadcast audio and video sources.
16
REFERENCES
[1] Robert McMillan, A RESTful Approach to Web Services, Network World, 17 Feb 03, Available at: http://www.nwfusion.com/ee/2003/eerest.html [2] Oliver Schmelzle, RESTful Web Services, XML AUSTIN USERS GROUP, 9 Apr 2003 Roger L. Costello, Representational State TransferAvailable at: http://www.xfront.com/REST.html [3] Roy Thomas Fielding, Architectural Styles and the Design of Network -based Software Architectures, UNIVERSITY OF CALIFORNIA, 2000 [4] Antone Gonsalves, New Distributed Computing Model Takes On SOAP, Web Services, Available at: http://www.internetwk.com/breakingNews/INW20021209S0010 [5] Suresh Chande, REST, University of Helsinki, 15 Mar, 2004 Available at: http://www.cs.helsinki.fi/u/chande/courses/cs/WSA/presentations/L13_REST.pdf [6] Kendall Grant Clark, Webs At Rest and In Motion, July 10, 2002 Available at: http://webservices.xml.com/pub/a/ws/2002/07/10/rest.html [7] L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice, Addison Wesley, Reading, Mass., 1998 [8] R. N. Taylor, N. Medvidovic, K. M. Anderson, E. J. Whitehead Jr., J. E. Robbins, K. A. Nies, P. Oreizy, and D. L. Dubrow. A component- and message-based architectural style for GUI software. IEEE Transactions on Software Engineering, 22(6), June 1996 [9] N. Freed, J. Klensin, and J. Postel. Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures, Internet RFC 2048, Nov. 1996 [10] D. E. Perry and A. L. Wolf. Foundations for the study of software architecture, ACM SIGSOFT Software Engineering Notes, Oct. 1992 [11] J. Mogul, R. Fielding, J. Gettys, and H. Frystyk. Use and Interpretation of HTTP Version Numbers, Internet RFC 2145, May 1997 [12] N. Freed and N. Borenstein. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. Internet RFC 2045, Nov. 1996 [13] H. F. Nielsen, P. Leach, and S. Lawrence. HTTP extension framework, Interne t RFC 2774, Feb. 2000 [14] Paul Prescod, Common http://www.prescod.net/rest/mistakes/ REST Mistakes, Feb 2002 Available at:
[15] Roger L. Costello, Building Web Services the REST Way Jun 2003 http://www.xfront.com/REST-Web-Services.html [16]Paul Prescod, Some thoughts about SOAP versus REST on Security http://www.prescod.net/rest/security.html
17