An overview of the current status - Twente Student Conference on IT

will show <strong>the</strong> details <strong>of</strong> this particular resource, whilePUT http://hostname/users/1/in combination with <strong>the</strong> information that needs to be updated,will update <strong>the</strong> resource, whileDELETE http://hostname/users/1/will delete <strong>the</strong> resource.The request:POST http://hostname/users/in combination with <strong>the</strong> information that needs to be entered fora new resource, creates a new resource.One can see in <strong>the</strong> example above that <strong>the</strong> action that needs tobe performed is not located in <strong>the</strong> URI. Also, one could forexample easily define rules in <strong>the</strong> firewall that would disallow<strong>the</strong> usage <strong>of</strong> PUT and DELETE on <strong>the</strong> internet, but allow <strong>the</strong>semethods on <strong>the</strong> intranet.A web service can ‘consume’ <strong>the</strong> resources above as if it is alocal resource. It can manipulate <strong>the</strong> resource by using differentAs we now know what REST’s characteristics are, we can lookinto more detail what <strong>the</strong> advantages and disadvantages <strong>of</strong> <strong>the</strong>secharacteristics are.2.2 The Advantages <strong>An</strong>d Disadvantages OfRESTThe addition <strong>of</strong> <strong>the</strong> constraints mentioned in <strong>the</strong> previousparagraph to <strong>the</strong> web, has several advantages and disadvantages.Below for each previously mentioned principle, <strong>the</strong> advantagesand disadvantages are explained.2.2.1 Uniform interface between componentsREST’s focus on a uniform interface between components is anadvantage as well as a disadvantage. The advantage is thatimplementations are no longer coupled to <strong>the</strong> services <strong>the</strong>yprovide. This means that if you write a RESTful webapplication that provides a certain service, o<strong>the</strong>r RESTful webapplications are able to communicate with that web applicationas if <strong>the</strong> service is a local resource. A uniform interface alsomeans that web applications should very easily be able to‘consume’ web services without a specification <strong>of</strong> <strong>the</strong> protocol<strong>the</strong> web services use. For example, if one writes a webapplication that uses a certain web service, <strong>the</strong> way <strong>of</strong> gettingand manipulating <strong>the</strong> information <strong>of</strong> that web service is definedby <strong>the</strong> uniform interface. Of course one still needs to know whatinformation <strong>the</strong> web service provides and what <strong>the</strong>characteristics are <strong>of</strong> <strong>the</strong> accessed information. Still, becauseone knows how to get and manipulate <strong>the</strong> information,accessing this web service can save both time and money.The usage <strong>of</strong> <strong>the</strong> HTTP methods GET, POST, PUT andDELETE also has an advantage. Currently <strong>of</strong>ten <strong>the</strong> POSTmethod is used to update or delete information. While <strong>the</strong> POSTmethod is not idempotent, <strong>the</strong> PUT and DELETE method are.Idempotent means that multiple identical requests have <strong>the</strong> sameeffect as one request. This means when a client uses PUT orDELETE, <strong>the</strong> client (and intermediaries) can make betterassumptions about <strong>the</strong> resource <strong>the</strong>y modified, than when <strong>the</strong>POST method was used.The uniform interface also has a disadvantage. A standardizedform <strong>of</strong> transferring information is less efficient thantransferring information in a format created specific for anapplication. REST is designed to be efficient for <strong>the</strong> mostcommon cases <strong>of</strong> <strong>the</strong> web, but it is not optimal for o<strong>the</strong>r forms<strong>of</strong> architectural interaction [Fie00].REST’s uniform interface is <strong>the</strong> aspect that differs <strong>the</strong> mostfrom o<strong>the</strong>r architectural styles, and protocols such as SOAP. Incontrast to REST, SOAP has a separate protocol layered overHTTP. This increases complexity compared to <strong>the</strong> directfetching <strong>of</strong> documents over HTTP that REST describes. Also asSOAP only uses GET and POST, firewalls are not able todistinguish <strong>the</strong> intent <strong>of</strong> a SOAP request [New05].2.2.2 Layered system styleThe use <strong>of</strong> <strong>the</strong> layered system style has <strong>the</strong> advantage <strong>of</strong> anoverall reduction <strong>of</strong> system complexity. It also encouragessubstrate independence. Layers can be applied so <strong>the</strong> systemcan use legacy services and protect new services from legacyclients. It also increases <strong>the</strong> easiness <strong>of</strong> using intermediaries.The major disadvantage <strong>of</strong> layered systems is <strong>the</strong> additionaloverhead and an increase in latency to data processing. Thesefactors lead to a reduction in performance <strong>the</strong> user experiences[CT90]. Sharing caches at intermediaries may solve some <strong>of</strong><strong>the</strong>se performance issues [WVS+99].2.2.3 Code-on-demand styleThe code-on-demand style also has advantages anddisadvantages. The major advantage is <strong>the</strong> ability to addfeatures to deployed clients. This results in improvedextensibility and configurability. Also <strong>the</strong> performance andefficiency that <strong>the</strong> user experiences, is increased as a) <strong>the</strong> codecan be adapted to <strong>the</strong> client’s local environment and b) <strong>the</strong> codecan interact with <strong>the</strong> client locally instead <strong>of</strong> remote. It alsoleads to an increased scalability <strong>of</strong> <strong>the</strong> server as <strong>the</strong> clientexecutes <strong>the</strong> code.The major drawback <strong>of</strong> <strong>the</strong> code-on-demand style is <strong>the</strong> lack <strong>of</strong>visibility, as <strong>the</strong> server sends code instead <strong>of</strong> data, and <strong>the</strong>reduction <strong>of</strong> simplicity, as <strong>the</strong> evaluation environment needs tobe managed.We now know what <strong>the</strong> characteristics and <strong>the</strong> advantages anddisadvantages <strong>of</strong> REST are.3. REST SUPPORT IN CURRENTAPPLICATIONSIf one wants to choose some architectural style for <strong>the</strong>development <strong>of</strong> web applications, it is important to know what<strong>the</strong> support that architectural style has in <strong>current</strong> availables<strong>of</strong>tware. Therefore below <strong>the</strong> <strong>current</strong> web client s<strong>of</strong>tware andweb server s<strong>of</strong>tware is analyzed to see whe<strong>the</strong>r support forREST is present or not. If support is not present, we add if <strong>the</strong>authors <strong>of</strong> <strong>the</strong> s<strong>of</strong>tware in question tend to support REST in <strong>the</strong>future.We will only analyze <strong>the</strong> s<strong>of</strong>tware on <strong>the</strong> constraints that RESTadds to <strong>the</strong> web concept, mentioned in §2.1. We presume allweb client and web server s<strong>of</strong>tware support <strong>the</strong> o<strong>the</strong>r threeconstraints.Not all constraints that REST adds to <strong>the</strong> web concept musthave support from ei<strong>the</strong>r web client or web server s<strong>of</strong>tware. Forexample, <strong>the</strong> constraint for <strong>the</strong> layered system style is largely aweb application specific constraint, which means <strong>the</strong> webdeveloper has to take this constraint into account whendeveloping his web application.During our analysis, we came to <strong>the</strong> conclusion that in generalmost web server s<strong>of</strong>tware (e.g. Apache, IIS) has support forREST, but that most constraints have little influence on webserver s<strong>of</strong>tware itself. Instead <strong>the</strong> constraints are more focusedon <strong>the</strong> platforms that run on <strong>the</strong> web servers, such as PHP, ASPand JSP. We <strong>the</strong>refore analyzed <strong>the</strong>se platforms in more detailin §3.1. In §3.2 we focused our analysis on <strong>the</strong> most <strong>of</strong>ten-usedweb browsers.

3.1 REST support in server platformsThese platforms should support REST in two ways: server sidesupport and client side support. Server side support is supportfor incoming connections from o<strong>the</strong>r clients. Client side supportis support for outgoing connections to o<strong>the</strong>r web servers (<strong>the</strong>same connections that web browsers make).We analyzed <strong>the</strong> following platforms that have both client sideand server side support:• ASP.NET [Cas07]• Java (JSP)• Perl• PHP• Python• RubyAs support for outgoing connections is not <strong>the</strong> same as supportfor incoming connections, we treated <strong>the</strong>m differently andanalyzed <strong>the</strong>m both.All former mentioned platforms have both client side and serverside support for REST. This means one can create a RESTfulweb application on all before mentioned platforms. Also <strong>the</strong>platforms are capable <strong>of</strong> starting connections to RESTfulservers.So in general one can conclude that <strong>the</strong> platforms can supportRESTful applications. Still, it is more interesting to see if <strong>the</strong>seplatforms encourage REST, for example through some kind <strong>of</strong>framework or library. Therefore we also tried to find, for eachbefore mentioned platform, if <strong>the</strong>re is a framework or libraryavailable that encourages <strong>the</strong> use <strong>of</strong> REST. In <strong>the</strong> table below,<strong>the</strong> results are displayed.Table 1: Frameworks that encourage <strong>the</strong> use <strong>of</strong> RESTPlatformASP.NETJava (JSP)Perl -PHPPythonRubyFramework / LibraryASP.NET MVC [Gut07][Haa07]JAX-RS [JCP07]Konstruct, Tonic, dbscript [Sem07],PHP REST SQL [Jam04]pyrest [Goo07a], Django [Goo07b]Ruby on Rails [RoR07]Micros<strong>of</strong>t is working on a model-view-controller framework,called ASP.NET MVC, although <strong>the</strong>re is not even a beta versionout right now [Gut07]. For Python <strong>the</strong>re is <strong>current</strong>ly a GoogleCode project for writing a library that should support REST, butnothing has been published on that page yet [Goo07a]. Besidesthat <strong>the</strong>re is a REST interface for Django [Goo07b]. The JavaCommunity Process Program is working on a library (JAX-RS)that should create a Java API for RESTful web services. Theplanned date for <strong>the</strong> final specification and referenceimplementation is March 2008 [JCP07]. Probably <strong>the</strong> mostfamous example <strong>of</strong> a framework that encourages REST is Rubyon Rails for <strong>the</strong> Ruby platform [Ror07]. For Perl <strong>the</strong>re is nolibrary or framework one could use to write RESTfulapplications, although <strong>the</strong>re are some examples <strong>of</strong> web servicesthat provide RESTful access in Perl. For PHP severalframeworks are available that encourages REST. We named afew in <strong>the</strong> table above, but <strong>the</strong>re are more [Sem07][Jam04].So although <strong>the</strong>re are some frameworks available, for mostplatforms frameworks or libraries are still in development.3.2 Web browsersWe use <strong>the</strong> latest stable version <strong>of</strong> <strong>the</strong> <strong>current</strong>ly most <strong>of</strong>ten usedweb browsers. The most used web browsers are: InternetExplorer, Firefox, Opera and Safari [W3S07]. The latest stableversions <strong>of</strong> <strong>the</strong>se web browsers are Internet Explorer 7 [Mic07],Firefox 2.0.0.11 [Moz07], Opera 9.24 [Ope07] and Safari 3.04[Wik07].We analyzed <strong>the</strong>se browsers for <strong>the</strong>ir support for <strong>the</strong> RESTconstraints. The browsers have <strong>the</strong> ability to confirm to most <strong>of</strong><strong>the</strong>se constraints, but not all.The code-on-demand style is <strong>of</strong>ten only supported by <strong>the</strong> use <strong>of</strong>plug-ins, for example Java applets and Flash applets. Supportfor <strong>the</strong> layered system style is present, but this is ra<strong>the</strong>r evident,as it is more a constraint that should be followed by <strong>the</strong> server.The self-descriptive messages are not fully supported by <strong>the</strong>previously mentioned web browsers. All previously mentionedweb browsers do not support <strong>the</strong> DELETE and PUT HTTPmethods. This is somewhat remarkable as <strong>the</strong> HTTP 1.0standard described <strong>the</strong>se four methods already in 1996[BFI+96]. However, <strong>the</strong> original HTML specification andfollowing versions disallow <strong>the</strong> use <strong>of</strong> <strong>the</strong> PUT and DELETEmethod [Har06]. Whe<strong>the</strong>r future versions <strong>of</strong> <strong>the</strong> HTMLspecification allow <strong>the</strong> use <strong>of</strong> <strong>the</strong> DELETE and PUT method isunknown. Still, <strong>the</strong> Web Forms 2.0 draft, supported by Firefox,Opera and Safari does include support for <strong>the</strong>se HTTP methods[Hic06], so we will probably see support in later versions <strong>of</strong><strong>the</strong>se web browsers.We also analyzed <strong>the</strong> XMLHttpRequest method in Javascript(used in AJAX calls), which is supported by <strong>the</strong>se browsers.This method does support <strong>the</strong> PUT and DELETE method[ATOM07]. With XMLHttpRequest, Javascript has fullysupport for REST, although creating RESTful web applicationsthrough <strong>the</strong> use <strong>of</strong> Javascript is a workaround that mayintroduce o<strong>the</strong>r problems.4. CONCLUSIONSWhat is REST?In §2.1 we explained that REST is an architectural style for <strong>the</strong>development <strong>of</strong> web applications. It is based on constraints thatare <strong>current</strong>ly applied to <strong>the</strong> web plus constraints based on threeprinciples: a uniform interface between components, <strong>the</strong> layeredsystem style and <strong>the</strong> code-on-demand style. We also gave anexample <strong>of</strong> what a RESTful application could look like.What are <strong>the</strong> advantages and disadvantages <strong>of</strong> using REST asan architectural style for <strong>the</strong> development <strong>of</strong> web applications?In §2.2 we described <strong>the</strong> advantages and disadvantages <strong>of</strong>REST. The main advantage <strong>of</strong> REST is that implementationsare no longer coupled to <strong>the</strong> service <strong>the</strong>y provide. Also <strong>the</strong> use<strong>of</strong> <strong>the</strong> idempotent PUT and DELETE HTTP methods are anadvantage. The layered system style reduces <strong>the</strong> overall systemcomplexity and <strong>the</strong> advantage <strong>of</strong> <strong>the</strong> code-on-demand style is<strong>the</strong> ability to add features to deployed clients.The main disadvantage <strong>of</strong> REST is efficiency and <strong>the</strong> perceiveduser experience. A standardized form <strong>of</strong> transferringinformation is less efficient than transferring information in aformat created specific for an application. The use <strong>of</strong> <strong>the</strong>layered system style leads to increased overhead, and <strong>the</strong> use <strong>of</strong><strong>the</strong> code-on-demand style leads to a decrease in visibility.What web server s<strong>of</strong>tware and web client s<strong>of</strong>twareimplementations support REST?In §3 we analyzed whe<strong>the</strong>r <strong>current</strong> s<strong>of</strong>tware has support forREST. The platforms we tested that support client sideconnections all support <strong>the</strong> constraints that REST apply. The

same is valid for <strong>the</strong> platforms we tested that support server sideconnections. This means <strong>the</strong> s<strong>of</strong>tware that runs on <strong>the</strong> server ingeneral has support for REST. In contrast to <strong>the</strong> s<strong>of</strong>tware thatruns on servers, all major web browsers do not support <strong>the</strong> selfdescriptivemessages constraint <strong>of</strong> REST.If a web server supports RESTful web applications, it does notmean <strong>the</strong> web applications are always RESTful. For someplatforms <strong>the</strong>re are frameworks available that encourage <strong>the</strong> use<strong>of</strong> REST. For o<strong>the</strong>r platforms, <strong>the</strong>re are frameworks or librariesin development.What is <strong>the</strong> <strong>current</strong> <strong>status</strong> <strong>of</strong> REST?The layered system style and <strong>the</strong> code-on-demand style thatREST uses are already present and <strong>of</strong>ten used in <strong>the</strong> modernweb. REST’s main feature, <strong>the</strong> uniform interface betweencomponents, is however not <strong>of</strong>ten used. Especially <strong>the</strong>constraint focused on <strong>the</strong> identification <strong>of</strong> resources and <strong>the</strong>self-descriptive messages constraint are in <strong>current</strong> webapplications <strong>of</strong>ten not taken into account. Web browsers notsupporting all HTTP methods can explain <strong>the</strong> lack <strong>of</strong> using selfdescriptivemessages. Why <strong>the</strong> identification <strong>of</strong> resourcesconstraint is not applied in web applications could be <strong>the</strong> focus<strong>of</strong> fur<strong>the</strong>r research. Fur<strong>the</strong>r research could also focus on <strong>the</strong>easiness <strong>of</strong> writing RESTful applications in <strong>the</strong> beforementioned platforms in §3.ACKNOWLEDGMENTSFirst <strong>of</strong> all we would like to thank dr. ir. A. Pras for hisguidance and feedback during this research. Secondly, manythanks to my colleagues for <strong>the</strong>ir invested time and constructivefeedback during our sessions toge<strong>the</strong>r.REFERENCES[ATOM07] ATOM Wiki, PUT and DELETE support,http://www.intertwingly.net/wiki/pie/PutDeleteSupport, last visit: November 26 th , 2007.[BHM+04] Booth, D., Haas, H., McCabe, F. et al. Web ServicesArchitecture, W3C Working Group Note, February11 th , 2004, http://www.w3.org/TR/2004/NOTE-wsarch-20040211/,last visit: September 23 rd , 2007.[Cas07][CT90][Ere04][Fie00][FPV98][Fra00]P. Castro, Overview: Micros<strong>of</strong>t Codename“Astoria”, Micros<strong>of</strong>t Corporation, April 2007.Clark, D.D., Tennenhouse, D.L. ArchitecturalConsiderations for a New Generation <strong>of</strong> Protocols,in: Proceedings <strong>of</strong> <strong>the</strong> ACM symposium onCommunications architectures & protocols,Philadelphia, Pennsylvania, 1990, p. 200-208.Erenkrantz, J.R. Web Services: SOAP, UDDI, andSemantic Web, Institute for S<strong>of</strong>tware Research,May, 2004.Fielding, R.T. Architectural Styles and <strong>the</strong> Design<strong>of</strong> Network-based S<strong>of</strong>tware Architectures,University <strong>of</strong> California, Irvine, 2000.Fuggetta, A., Picco, G.P., Vigna, G. Understandingcode mobility, in: IEEE Transactions on S<strong>of</strong>twareEngineering, 24:5, May 1998, p. 342-361.Fraternali, P. Tools and Approaches for DevelopingData-Intensive Web Applications: A Survey, in:ACM Computing Surveys (CSUR), 31:3, September,1999, p. 227-263.[Goo07a] Google Code, Python REST library,http://code.google.com/p/pyrest/, last visit:December 17 th , 2007.[Goo07b] Google Code, Django REST interface,http://code.google.com/p/django-rest-interface/, lastvisit: December 17 th , 2007.[Gut07][Haa07]Guthrie, S. ASP.NET MVC Framework, October,14 th , 2007,http://weblogs.asp.net/scottgu/archive/2007/10/14/asp-net-mvc-framework.aspx, last visit: December17 th , 2007.Haack, P. The REST-Like aspect <strong>of</strong> ASP.NET MVC,November 10 th , 2007,http://haacked.com/archive/2007/11/10/<strong>the</strong>-restlike-aspect-<strong>of</strong>-asp.net-mvc.aspx,last visit:December 17 th , 2007.[Har06] Harold, E. Why REST Failed, October 26 th , 2006,http://cafe.elharo.com/web/why-rest-failed/, lastvisit: October 22 nd , 2007.[Hic06] Hickson, I. Web Forms 2.0, October 12 th , 2006,http://www.whatwg.org/specs/web-forms/<strong>current</strong>work/,last visit: October 22 nd , 2007.[Jam04] James, P. PHP REST SQL, 2004,http://phprestsql.sourceforge.net/, last visit:December 17 th , 2007.[JCP07][Mic07]Java Community Process, Java SpecificationRequest 311: JAX-RS: The Java API for RESTfulWeb Services, April 5 th , 2007,http://jcp.org/en/jsr/detail?id=311, last visit:December 17 th , 2007.Micros<strong>of</strong>t, Internet Explorer,http://www.micros<strong>of</strong>t.com/windows/products/winfamily/ie/default.mspx, last visit: December 4 th , 2007.[MNS04] zur Muehlen, M., Nickerson, J.V., Swenson, K.D.Developing web services choreography standards -<strong>the</strong> case <strong>of</strong> REST vs. SOAP, Elsevier, 2004.[Moz07][New05][Ope07][Orc06][Prz06][RoR07][Sem07][Sze06]Mozilla, Mozilla Firefox 2.0.0.11 Release Notes,November 30 th , 2007, http://www.mozilla.com/en-US/firefox/2.0.0.11/releasenotes/, last visit:December 4 th , 2007.Newmarch, J. A. RESTful Approach: Clean UPnPwithout SOAP, in: Consumer Communications andNetworking <strong>Conference</strong> (CCNC), 2005. IEEE,January, 2005, p. 134-138.Opera, Opera Browser,http://www.opera.com/products/desktop/, last visit:December 4 th , 2007.Orchard, D., Hypermedia as <strong>the</strong> engine <strong>of</strong> statetransfer, March 31 st , 2006,http://www.pacificspirit.com/2006/03/31/hypermedia_as_<strong>the</strong>_engine_<strong>of</strong>_state_transfer, last visit:December 4 th , 2007.Przybilski, M. REST – REpresentational StateTransfer, University <strong>of</strong> Helsinki, 2006.Ruby on Rails, Ruby on Rails,http://www.rubyonrails.org/, last visit: December17 th , 2007.SemWebDev Weblog, PHP RESTful Frameworks,July 2 nd , 2007,http://semwebdev.keithalexander.co.uk/blog/posts/rest-frameworks-php, last visit: December 17 th , 2007.Szepielak, D. REST-Based Service OrientedArchitecture for Dynamically Integrated

[Tat06]Information Systems, PhD Symposium at ICSOC,2006.Tate, B. Crossing borders: REST on Rails, August1 st , 2006,http://www.ibm.com/developerworks/java/library/jcb08016/,last visit: September 30 th , 2007.[W3S07] W3Schools, Browser Statistics, October 2007,http://www.w3schools.com/browsers/browsers_stats.asp, last visit: December 4 th , 2007.[Wik07]Wikipedia, Safari (web browser),http://en.wikipedia.org/wiki/Safari_(web_browser),last visit: December 4 th , 2007.[Wil07]P. Williams, Hypermedia as <strong>the</strong> engine <strong>of</strong>application state, May 23 rd , 2007,http://pezra.barelyenough.org/blog/2007/05/hypermedia-as-<strong>the</strong>-engine-<strong>of</strong>-application-state/, last visit:December 4 th , 2007.[WVS+99] Wolman, A., Voelker, G., Sharman, N. et al.Organizational-Based <strong>An</strong>alysis <strong>of</strong> Web-ObjectSharing and Caching, in: Proceedings <strong>of</strong> <strong>the</strong> 2 ndconference on USENIX Symposium on InternetTechnologies and Systems, Boulder, Colorado,October, 1999.