Today's Top "RESTful" Services and Why They Are Not RESTful

2,171 views
2,077 views

Published on

Presentation of WISE 12 Paper "Today's Top "RESTful" Services and Why They Are Not RESTful" (Renzel, Schlebusch, Klamma)

Abstract: Since Fielding's seminal contribution on the REST architecture style in 2000, the so-called class of RESTful services has taken o ff to challenge previously existing Web services. Several books have since then emerged, providing a set of valuable guidelines and design principles for the development of truly RESTful services. However, today's most popular "RESTful" services adopt only few of these guidelines, resulting in overburdening developers integrating multiple services in mashup applications. In this paper we present an in-depth analysis for the top 20 RESTful services listed on programmableweb.com against 17 RESTful service design criteria found in literature. Results provide evidence that hardly any of the services claiming to be RESTful is truly RESTful, probably due to the lack of rigidness and ease-of-use of currently available decision criteria. To improve the situation, we provide recommendations for various stakeholder groups.

Full Paper: http://www.springerlink.com/index/42307200X642M240.pdf

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,171
On SlideShare
0
From Embeds
0
Number of Embeds
233
Actions
Shares
0
Downloads
13
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Today's Top "RESTful" Services and Why They Are Not RESTful

  1. 1. The 13th International Conference on Web Information Systems Engineering (WISE 2012) November 28th-30th, 2012 Paphos, Cyprus. Today’s Top “RESTful” Services and Why They Aren’t RESTful Dominik Renzel, Patrick Schlebusch, Ralf Klamma RWTH Aachen University Advanced Community Information Systems (ACIS) Aachen, Germany renzel@dbis.rwth-aachen.deLehrstuhl Informatik 5(Information Systems) Prof. Dr. M. Jarke 1 These presentation slides by Dominik Renzel are licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
  2. 2. Advanced Community Information Systems (ACIS) Responsive Web Engineering Community Web Analytics Open Visualization Community and Information Simulation Systems Community Community Support AnalyticsLehrstuhl Informatik 5 Requirements(Information Systems) Prof. Dr. M. Jarke 2 Engineering
  3. 3. Motivation Service Service HELP!  Huge variety of Communities of Practice in the Long Tail  Lack of custom tools for niche communities  Common in Web CIS: “RESTful“ APIs as (part of) products  Mash-ups become possibleLehrstuhl Informatik 5(Information Systems) Prof. Dr. M. Jarke Great! Aren‘t we happy? Well, partially yes, but… 3
  4. 4. RESTful Services – Problems in Practice Theory Design Guidelines Dev Frameworks But: Lack of compliance to RESTful principles  Increased workload & costs for service integration  Bad mash-up code quality  Lower customer satisfaction (developers & end-user communities)  Automatic compliance checks hardly possible  Lower overall service success (community practice & provider revenue)Lehrstuhl Informatik 5(Information Systems) Prof. Dr. M. Jarke Study: How RESTful are today‘s top “RESTful“ services? 4
  5. 5. Methodology  Check adherence of 20 APIs…  … to 17 RESTful design principles  Data sources – API descriptions from programmableweb.com (Top 20 by popularity; 53% coverage of mash-ups; May 2011) – Respective official API documentation – 17 RESTful design principles (here only excerpt) – REST dissertation (Fielding, 2000) – RESTful service design principles (Richardson & Ruby, 2007) – Related HTTP protocol features  Manual analysisLehrstuhl Informatik 5(Information Systems) Prof. Dr. M. Jarke 5
  6. 6. Results Overview Amazon Product Advert. Google Content/Search Google Custom Search Yahoo Local Search Yahoo Placefinder Facebook Graph Google Charts Amazon EC2 Yahoo Map Amazon S3 GeoNames MediaWiki del.icio.us Box.net Twitter last.fm Twilio Flickr ebay Digg Formal Description Links in Representations Forms in Representations Resource Types Versioned Endpoint Scoping Information Parameter Sources Meaningful HTTP Status Use of HTTP MethodsLehrstuhl Informatik 5 HTTP Method Override(Information Systems) Prof. Dr. M. Jarke Format Selection 6
  7. 7. Availability of Formal Description  Benefits – Usable documentation – Better service discovery & integration 4, 20% 1, 5% WSDL Response XML Schema 15, 75% None  Good examples  Bad examplesLehrstuhl Informatik 5 Amazon, ebay, Yahoo Local Search Twitter, Flickr and many more(Information Systems) Prof. Dr. M. Jarke 7
  8. 8. Links in Representations  Benefits – Links as possible follow-up actions  navigational help – HATEOAS as part of "uniform interface“ (Fielding 2000) 4, 20% Links used No Links 16, 80%  Good examples  Bad examplesLehrstuhl Informatik 5 Twilio, Google Custom Search Twitter, Flickr and many more(Information Systems) Prof. Dr. M. Jarke 8
  9. 9. Forms in Representations & Parameter Sources  Benefits – Better information on structure and semantics of user input – Formal description of request construction 1, 5% 3, 15% 1, 5% Both Forms Used No Forms Form-encoded Content 19, 95 16, 80% Query Parameter % Forms in Representations Parameter Sources  Good examples  Bad examples – Google Custom (in repr.) Twitter, Flickr, DiggLehrstuhl Informatik 5(Information Systems) – Last.fm, Twilio (Both param sources) Prof. Dr. M. Jarke 9 – Ebay (form-encoded params)
  10. 10. Number of Resource Types  Benefits – Grouping resources by functionality/semantics – Good indicator for “RPC-style disguised as RESTful“ 5, 25% Multiple 8, 40% Single Overloaded 7, 35%  Good examples  Bad examplesLehrstuhl Informatik 5 – Twitter (multiple) – Flickr (single overloaded) – Google Custom Search (single) – Box.net (few overloaded)(Information Systems) Prof. Dr. M. Jarke 10
  11. 11. Versioned Endpoints  Benefits – Avoids breaking consumer applications after new releases – Indicates service development activity 7, 35% yes no 13, 65%  Good examples  Bad examplesLehrstuhl Informatik 5 Twitter, delicio.us, last.fm Amazon EC2, Google Charts(Information Systems) Prof. Dr. M. Jarke 11
  12. 12. Meaningful Usage of HTTP Methods & Status Codes  Benefits – Well-defined operational semantics for HTTP methods – Well-defined vocabulary for communicating success/problems to clients 25 20 15 Bad 6, 30% 10 yes Reasonable 5 no 14, 70% 0 GET POST DELETE PUT Meaningful Use of Methods Meaningful Use of Status Codes  Good examples  Bad examplesLehrstuhl Informatik 5 Twitter, flickr, Twilio del.icio.us, digg(Information Systems) Prof. Dr. M. Jarke 12
  13. 13. Conclusions General Finding: “REST-smattering“ – Mixed adoption of REST concepts among top services – Deliberate decisions or ongoing misconceptions – Often rather buzzword than compliance – Disadvantages for users & providers  Antidote: Increased formalization – Enables helpful tools & KPIs – Requires wide support by research & industry – Reduces complexity in service orchestrationLehrstuhl Informatik 5 – Cure on the way from research, industry to support!(Information Systems) Prof. Dr. M. Jarke 13
  14. 14. Questions? Contact: renzel@dbis.rwth-aachen.deLehrstuhl Informatik 5(Information Systems) Prof. Dr. M. Jarke 14

×