RESTful Web Services

1

1. 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.

1.1. What is REST?

The name “Representational State Transfer” is intended to evoke an image of how a well-designed Web application behaves; REST is not intended to capture all possible uses of the Web protocols standards. There are applications of HTTP (HyperText Transfer Protocol) and URI (Universal Resource Identifier) that do not match the application model of a distributed hypermedia system. The important point, is that REST does capture all of those aspects of a distributed hypermedia system that are considered central to the behavioural and performance requirements of the Web, such that optimizing behaviour within the model will result in optimum behaviour within the deployed Web architecture. In other words, REST is optimized for the common case so that the constraints it applies to the Web architecture will also be optimized for the common case [3].

REST is good method for building Web services. REST is more an old philosophy than a new technology, the REST philosophy espouses that the existing principles and protocols of the Web are enough to create robust Web services. This means that developers who understand HTTP and XML can start building Web services, without needing any toolkits beyond what they normally use for Internet application development.

1.2. Why is REST Important?

Roy Fielding said, “REST scales well with large numbers of clients, enables transfer of data in streams of unlimited size and type, supports intermediaries (proxies and gateways) as data transformation and caching components, and concentrates the application state within the user agent components.” [3]. As we know, the Web is the most successful example of an environment that allows for interoperability among a large number of otherwise uncoordinated actors, and inasmuch as that is a desirable trait in a computing environment, the REST model provides a valuable framework.

2 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.

3

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 ,Self-descriptive 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].

4

3. RESTFUL WEB SERVICES

REST is an architectural style that models system behaviour for network-based applications. When an application on the Web is implemented according to that style, it inherits the interconnectivity characteristics already present in the Web. REST's purpose is to describe the characteristics of the Web such that they can be used to maximum advantage. REST is supposed to be a guide to understanding the design trade-offs, why they were made, and what properties we lose when an implementation violates them.

REST is a model for distributed computing. It is the one used by the world's biggest distributed computing application, the Web. When applied to web services technologies, it usually depends on a trio of technologies designed to be extremely extensible: XML, URIs, and HTTP. XML's extensibility should be obvious to most, but the other two may not be.

3.1. REST Web Services Characteristics

REST emphasizes restraint and understanding of the system context. 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 [RTF00].

As mentioned in the Introduction section, REST, as an architectural style, 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 [6]. Below is a short summary of the REST’s characteristics, which motivate the REST to make the Web successful. Subsequently these characteristics are being used to guide the evolution of the Web.

3.1.1.Client-Server:

a pull-based interaction style: consuming components pull representations.

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.3.Cache:

to improve network efficiency responses must be capable of being labelled as cacheable or non-cacheable.

3.1.4.Uniform interface:

all resources are accessed with a generic interface (e.g., HTTP GET, POST, PUT, and DELETE).

5

3.1.5.Named resources:

the system is comprised of resources, which are named using a URL.

3.1.6.Interconnected resource representations:

the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another.

3.1.7.Layered components:

intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, etc.

3.2. REST vs. Other Web Services

Table 1. Comparison between REST and Web Services

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

REST Web Services

Uses the HTTP methods

Only the 1

st

generation uses the HTTP Post Uses URL to identify the desired resource Uses SOAPenveloping to identify the desired

procedure to be invoked Security is implemented by standard and

traditional solutions for authorized access to certain web resources

Security in SOAP requires additional infrastructure in Web to enable message transport level security concerns

Every entity in the Web is centred around resource

Every entity is centred around interfaces and messages that are channelled into the interface

A better approach for open systems A good approach for closed systems Utilises the caching mechanism No caching capabilities

Standard manipulation of resources based on URI

Manipulation of data is based on the message internal structure and application protocols An architectural style An RPC/Document oriented architectures WRDL provides the description to the web

resource

WSDL provides the description to services interfaces which can receive and deliver SOAP Messages

6 aspects of security, WS entity and identifiers. Table 1 gives a general overview of the comparisons between REST and WS [6].

3.2.1. REST vs SOAP

In a sense, people usually compare REST with SOAP. In fact, we should not make the contrast between them. REST is an architectural style rather than a standard or a protocol; we cannot see that W3C put REST as a specification. Our aim is to understand it and design our Web services in the style. In order to distinguish REST from SOAP, the following points may give an explanation.

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

3.2.1.2. Generic Interfaces

Table 3. Generic Interfaces

REST

- REST emphasizes standardized, generic operations

- SQL, file systems and other techniques are widely used

- HTTP methods (PUT, GET, POST, DELETE)

URI-7 identified resources

SOAP

- SOAP does not provide for generic operations

- Each application defines it’s own set of operations

- Creates need for description, discovery mechanisms

- Knowledge of semantics of operation is out-of-band

3.2.1.3. State Management

Table 4. State Management

REST

- REST application have explicit state transitions

- Servers and intermediaries are inherently stateless

- Resources contain data, links to valid state transitions

- Clients maintain state, traverse links in generic manner

SOAP

- SOAP application have implicit state transitions

- Servers and intermediaries may be stateless - Messages contain only data

- Clients maintain state, require knowledge of state machine

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.

8

3.2.1.6. Developer Support

REST developers are in the minority, and most vendors say enterprise users are not demanding REST services yet. But REST is generating a buzz, and is poised to capitalize on any market sentiment that SOAP based Web services are over-hyped. Major application development tool vendors, such as BEA Systems, IBM and Microsoft offer SOAP based kits for Web services development [1].

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 Internet’s 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.

3.3. REST Principles

The key to creating Web Services in a REST network is to identify all of the conceptual entities that you wish to expose as services. The principles of REST involve stateless conversation, cacheable representations, resource addressability, intermediaries and resource discovery. In this section, we will focus on these key principles.

“Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their uses.”

9

3.3.1. Key Principles of REST

The REST approach is open to Web application developers. In short and in principle, anyone, no matter what other technical loyalties, constraints, or commitments they've undertaken, is free to employ REST principles when building Web applications. In other words, theoretically, at least, every Web developer could use REST to build her or his next Web applications. As the marketers say, REST has a great upside [7]. Web consists of addressable resources. When a user utilizing an application selects a specific address, a specific representation of that resource is returned over the Web. This representation places the client application into a specific state. On accessing another specific address, the client application gets another representation of the resource and in turn transferring that state from the current to the new state.

When we talk about the key principles of REST, we should think about what the REST emphasizes. In talked in the previous sections, the scalability, generality, resource addressability, resolvability and extensibility are the key issues.

• “Identification of resources”

The Web is comprised of resources, while a resource is any item of interest or resources are anything that can be named. An identifier of a resource is assigned by authorizing the resource names.

• “Manipulation of resources through representations”

Representations are transferred between components and often contain the links to related resources, and representations also capture the current and intended state of resources.

• “Self-descriptive messages”

REST constrains messages between components to be self-descriptive in order to support intermediate processing of interactions. There should be several intermediaries introduced between the client and the ultimate resource, such as proxies, gateways, for caching, security, performance and so forth.

• “Hypermedia as the engine of application state”

Servers are stateless; all the requests originating from a client and server should contain the entire required context for the communication and cannot take advantage of any stored data. The messages are independent, and the clients maintain the state representations and traverse links.

• “Resource Addressability”

The resources are addressable by using URLs and are in turn interconnected via URLs. • “Resource Discovery”

The resource discovery is a standardized manner of discovering by using DNSand referring to resources.

3.4. REST Architectural Style

REST provides a set of architectural constrains that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of

10 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.

3.4.1. REST Architectural Approach

The early Web architecture was based on solid principles: separation of concerns, simplicity, and generality--but lacked an architectural description and rationale. The design was based on a set of informal hypertext notes [3]. Roy Fielding firstly defines a framework for understanding the software architectures by means of defining architectural styles, which can be used to guide the architectural design of the network-based application. And an architectural style can be used to define the principles behind the Web architecture such that they are visible to future architects.

A style is a named set of constraints on architectural elements that induces the set of properties desired of the architecture. Additional constraints can be applied to an architectural style in order to extend the set of properties induced on instantiated architectures. REST is the new architectural style which has guided the design of the modern Web Architectures. Using the new architectural style as a guide, we can compare proposed extensions and modifications to the Web architecture against the constraints within the style. Conflicts indicate that the proposal would violate one or more of the design principles behind the Web. In some cases, the conflict could be removed by requiring the use of a specific indicator whenever the new feature is used, as is often done for HTTP extensions that impact the default cache-ability of a response. For severe conflicts, such as a change in the interaction style, the same functionality would either be replaced with a design more conducive to the Web's style, or the proposer would be told to implement the functionality as a separate architecture running in parallel to the Web. In the following subsections, I will introduce the REST architectural styles properties, classifications and the aspects of REST.

3.4.2 . REST Architectural Properties

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. 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 [9]. In Fielding’s Ph.D dissertation, Fielding pointed out that the goal of architectural design is to create architecture with a set of architectural properties that form a superset of the system requirements. The

11 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.

3.4.3. REST Architectural Classifications

An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style [3] [7]. The purpose of building software is not to create a specific topology of interactions or use a particular component type, instead, it is to create a system that meets or exceeds the application needs. The architectural styles chosen for a system's design must conform to those needs, not the other way around. Therefore, in order to provide useful design guidance, a classification of architectural styles should be based on the architectural properties induced by those styles.

3.4.3.1. Data-Flow Styles

In a pipe and filter (PF) style, each component (filter) reads streams of data on its inputs and produces streams of data on its outputs, usually while applying a transformation to the input streams and processing them incrementally so that output begins before the input is completely consumed. This style is also referred to as a one-way data flow network. The constraint is that a filter must be completely independent of other filters (zero coupling): it must not share state, control thread, or identity with the other filters on its upstream and downstream interfaces

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

12 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]

3.4.3.2. Replication Styles

The Replicated Repository (RR) style improves accessibility to data and service response time by making the same data to be provided by more than one process.

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.

3.4.3.3. Hierarchical Styles

As the style name implicates, hierarchical styles are such styles like Client-Server styles and Layered System styles. There are a couple of sub-styles included in the hierarchical styles, the typical styles are Client-Server style (CS), Layered System/Client-Server style (LS), Client-stateless Server style, Client Cache-Stateless Servers style, Layered Client Cache Stateless Server style (LCS), Remote Session style and Remote Data Access style. Figure 3 generally presents the evaluations of hierarchical styles for network-bases systems [3].

13

Figure 3. Hierarchical Styles

3.4.3.4. Mobile Code Styles

Mobile code styles use mobility in order to dynamically change the distance between the processing and source of data or destination of results. The sub-styles included are Virtual Machine style (VM), Remote Evaluation style (REV), Code on Demand style (CoD), Layered CoD Client Cache Stateless Server style (LCODC$SS) and Mobile Agent style (MA). Figure 4 generally presents the evaluations of Mobile Code styles for network-based systems [3].

Figure 4. Mobile Code Styles

3.4.3.5. Peer-to-Peer Styles

Opposite to Hierarchical styles, Peer-to-Peer styles implicate the relationships between the objects. The involved typical sub-styles are: Event Based Integration style (EBI), C2 , architectural style, Distributed Object style (DO) and Brokered Distributed Object style (BDO).

14 This section is describes the applications from applying REST architectural style while authoring the Internet standards for HTTPand URI.

3.5.1. REST Applied to HTTP

The HTTP has a special role in the Web architecture as both the primary application-level protocol for communication between Web components and the only protocol designed specifically for the transfer of resource representations. The key problems in HTTP were identified by REST included planning for the deployment of new protocol versions, separating message parsing from HTTP semantics and the underlying transport layer, distinguishing between authoritative and non-authoritative responses, fine-grained control of caching, and various aspects of the protocol that failed to be self-descriptive. REST has also been used to model the performance of Web applications based on HTTP and anticipate the impact of such extensions as persistent connections and content negotiation. Finally, REST has been used to limit the scope of standardized HTTP extensions to those that fit within the architectural model, rather than allowing the applications that misuse HTTP to equally influence the standard. [3]

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 protocol’s 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]

15

3.5.1.2. Self-descriptive Messages

One of the worst mistakes in the early HTTP design was the decision not to send the complete URI that is the target of a request message, but rather send only those portions that were not used in setting up the connection. There were aspects of early HTTP that failed to be self-descriptive, including the lack of host identification within requests, failure to syntactically distinguish between message control data and representation metadata, failure to differentiate between control data intended only for the immediate connection peer versus metadata intended for all recipients, lack of support for mandatory extensions, and the need for metadata to describe representations with layered encodings [3]. REST constrains messages between components to be self-descriptive in order to support intermediate processing of the interactions.

3.5.1.3. REST Mismatches in HTTP

There are several architectural mismatches present within HTTP, some due to 3rd-party extensions that were deployed external to the standards process and others due to the necessity of remaining compatible with deployed HTTP components [3]. The mismatches are generated because of several reasons, such as HTTP cookies, differentiation from non-authoritative responses, mandatory extensions and mixing metadata.

3.5.1.3.1.

HTTP Cookies : Cookie interaction fails to match REST's model of application

state, often resulting in confusion for the typical browser application. An HTTP cookie is opaque data that can be assigned by the origin server to a user agent by including it within a Set-Cookie response header field, with the intention being that the user agent should include the same cookie on all future requests to that server until it is replaced or expires. Cookies violate REST as well, because they allow data to be passed without sufficiently identifying its semantics, thus becoming a concern for both security and privacy. Consequently, cookie-based applications on the Web will never be reliable. [3]

3.5.1.3.2.

Differentiation from non-authoritative responses : One of the HTTP’s

weaknesses is that there is no consistent mechanism for differentiating between authoritative responses, which are generated by the origin server in response to the current request, and non-authoritative responses that are obtained from an intermediary or cache without accessing the origin server.

3.5.1.3.3.

Mandatory extensions : A major protocol revision or a substantial change to

method semantics is required by mandatory header field extensions [11]. This is an aspect of the modern Web architecture, which does not yet match the self-descriptive messaging constraints of the REST architectural style, primarily because the cost of implementing a mandatory extension framework within the existing HTTP syntax exceeds any clear benefits that we might gain from mandatory extensions [3].

16

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 Fielding’s dissertation and Chahde’s 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 REST’s 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-of-service, and representations consisting of continuous data streams, such as those generated by broadcast audio and video sources.

17

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 Transfer”Available 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”, Internet RFC 2774, Feb. 2000

[14] Paul Prescod, “Common REST Mistakes”, Feb 2002 Available at: http://www.prescod.net/rest/mistakes/

[15] Roger L. Costello, “Building Web Services the REST Way” Jun 2003 Available at: http://www.xfront.com/REST-Web-Services.html

[16]Paul Prescod, “Some thoughts about SOAP versus REST on Security” Available at: http://www.prescod.net/rest/security.html