RESTfull Web Services.docx

RESTfull Web Services

Prepared By: Abdullah Mohammed Al-Sakkaf (815186)

2014

2014

RESTfull Web Services By: Abdullah M. Al-Sakkaf

RESTfull Web Services

When we talk about web services there are two solutions raised up: SOAP Web

Services and Restful Web Services. Each of them have it’s own characteristic and features to accomplish there jobs. Actually there some similarities and differences between them we will discuss it in the paper. Researchers and developers are now considering RESTful Web services as an alternative that might be more adequate than SOAPbased Web services in some

cases. RESTful Web services are deemed more lightweights because they don’t use SOAP or any other application layer protocol except for HTTP. (Christensen, 2009)

Introduction REST is an acronym for REpresentative State Transfer. It was first introduced in the doctoral dissertation of Roy Thomas Fielding in 2000. (Fielding, 2000) REST is a style, not a standard. There is neither a REST RFC, nor a REST protocol specification nor something similar. 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. Roy Fielding described REST as an architecture style, which attempts

“to minimize latency and network communication, while at the same time maximizing the independence and scalability of component implementations” 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. By examining the impact of each constraint as it is added to the

evolving style, we can identify the properties induced by the Web’s constraints. Additional constraints can then be applied to form a new architectural style that better reflects the desired properties of a modern Web architecture. This section provides a general overview of REST by walking through the process of deriving

2

it as an architectural style. Later sections will describe in more detail the specific constraints that compose the REST style. (Tilkov, 2008) Even though REST is heavily influenced by the Web ‐Technology, in theory the REST architecture style is not bound to HTTP. However, HTTP is the only relevant instance of the REST. For this reason this article describes REST implemented by using HTTP. Often this is called RESTful HTTP. The idea behind RESTful HTTP is to use the existing features and capabilities of the WEB. REST does not invent new technologies, components or services. RESTful HTTP defines the principles and constrains to use the existing WEB ‐ Standards in a better way.

REST Characteristics The key aspects of REST that make it desirable for mobile applications are these: 

REST is stateless, o



REST is URL based, o





Minimizing the impact of network volatility

Therefore easy to invoke

REST responses are usually HTTP based, o

Therefore discrete

o

Also minimizes the impact of network volatility.

REST delivery can be made very succinct o

Lends itself to constrained memory environments.

o

No superfluous protocol elements

REST as the connectivity layer REST makes a nice connectivity layer between cloud environments and mobile platforms, especially when used in conjunction with HTTP. The ease of generating the request is a convenience in environments where formulating complex XML tree structures is both cumbersome and expensive in terms of memory and processing.

3

RESTfull Web Services By: Abdullah M. Al-Sakkaf The response is discrete, minimal in its form, and since it, at times, only includes minimal HTTP headers and is therefore memory friendly. We can determine the outcome by using standard HTTP error codes, and the body is either empty, or contains the minimal set of data required to satisfy the request. The body can be encoded binary information, text, XML, or HTML depending on the prearranged agreement between the client and server. This direct resource based response significantly reduces the time, processor, and memory resources required to process a REST response in order to transform it to a state in which it is usable by the application.

RESTfull Strengths 

RESTful Web services are perceived to be simple because REST leverages existing well-known W3C/IETF standards (HTTP, XML, URI, MIME) and the necessary infrastructure has already become pervasive.



HTTP clients and servers are available for all major programming languages and operating system/hardware platforms



The default HTTP port 80 is commonly left open by default in most firewall configurations.



The effort required to build a client to a RESTful service is very small as developers can begin testing such services from an ordinary Web browser, without having to develop custom client-side software.



Deploying a RESTful Web service is very similar to building a dynamic Web site.



Furthermore, thanks to URIs and hyperlinks, REST has shown that it is possible to discover Web resources without an approach based on compulsory registration to a (centralized) repository.



On the operational side, it is known how to scale a stateless RESTful Web service to serve a very large number of clients, thanks to the support for caching, clustering and load balancing built into REST.

4



REST optimize the performance of a Web service, due to the possibility of choosing lightweight message formats, e.g., JSON or, even plain text for very simple data types. (Pautass, 2008)

Weaknesses 

Lake of standards, thus, only 2 verbs (GET for idempotent requests, and POST for everything else) are used. This is due to the fact that proxies and firewalls may not always allow HTTP connections that use any other verb. Also, POST and GET are the only two verbs that can be used in the method attribute of an XHTML form5. These restrictions have led to a series of

workarounds, where the “real” verb is sent using either a special HTTP header (X-HTTP-Method-Override) or – like with Ruby on Rails – a hidden

form field (−method). 

For idempotent requests having large amounts of input data (more than 4 KB in most current implementations) it is not possible to encode such data in the resource URI, as the server will reject (HTTP Code 414 Request-URI too long ). Inherently, the POST method does not suffer from such limitations.



Absent of some Enterprise level features: o

o

ACID properties! Enterprise security features!

Performance According to Belqasmi (2012) study it show that processing SOAPbased Web service requests in a mobile environment can take 10 times longer and consume eight times more memory than an equivalent RESTful Web service request. The differences between the execution delays in a distributed environment and in a single machine approximate the network delays for transferring messages through the network. These differences are two to four times higher for SOAP requests. This can be explained by the SOAP overhead in terms of network load. This overhead is due to the mandatory SOAP body (which, for instance, must be

sent to get conference information, while the counterpart RESTful request’s body 5

RESTfull Web Services By: Abdullah M. Al-Sakkaf is empty) and the extra information added in SOAP messages (such as the SOAP envelope). The network load over head is two to three times less when using a REST interface.

References Belqasmi, F., Singh, J., YOUNIS BANI MELHEM, S., & Glitho, R. H. (2012). Soapbased vs. restful web services: A case study for multimedia conferencing. IEEE internet computing, 16(4), 54-63. Christensen, J. H. (2009, October). Using RESTful web-services and cloud computing to create next generation mobile applications. In Proceedings of the 24th ACM SIGPLAN conference companion on Object oriented programming systems languages and applications (pp. 627-634). ACM. Fielding, R. T. (2000). Architectural styles and the design of network-based software architectures (Doctoral dissertation, University of California, Irvine). Pautasso, C., Zimmermann, O., & Leymann, F. (2008, April). Restful web services vs. big'web services: making the right architectural decision. In Proceedings of the 17th international conference on World Wide Web (pp. 805-814). ACM. Tilkov, S. (2008). A brief introduction to REST, 2007. URL http://www. infoq. com/articles/rest-introduction.[Online.

6