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 off 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
Tech-Forward - Achieving Business Readiness For Copilot in Microsoft 365
Today's Top "RESTful" Services and Why They Are Not RESTful
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.de
Lehrstuhl 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. Advanced Community
Information Systems (ACIS)
Responsive
Web Engineering Community
Web Analytics
Open
Visualization
Community
and
Information
Simulation
Systems
Community Community
Support Analytics
Lehrstuhl Informatik 5
Requirements
(Information Systems)
Prof. Dr. M. Jarke
2
Engineering
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 possible
Lehrstuhl Informatik 5
(Information Systems)
Prof. Dr. M. Jarke
Great! Aren‘t we happy? Well, partially yes, but…
3
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. 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 analysis
Lehrstuhl Informatik 5
(Information Systems)
Prof. Dr. M. Jarke
5
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 Methods
Lehrstuhl Informatik 5 HTTP Method Override
(Information Systems)
Prof. Dr. M. Jarke
Format Selection
6
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 examples
Lehrstuhl Informatik 5
Amazon, ebay, Yahoo Local Search Twitter, Flickr and many more
(Information Systems)
Prof. Dr. M. Jarke
7
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 examples
Lehrstuhl Informatik 5
Twilio, Google Custom Search Twitter, Flickr and many more
(Information Systems)
Prof. Dr. M. Jarke
8
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, Digg
Lehrstuhl Informatik 5
(Information Systems)
– Last.fm, Twilio (Both param sources)
Prof. Dr. M. Jarke
9
– Ebay (form-encoded params)
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 examples
Lehrstuhl Informatik 5
– Twitter (multiple) – Flickr (single overloaded)
– Google Custom Search (single) – Box.net (few overloaded)
(Information Systems)
Prof. Dr. M. Jarke
10
11. Versioned Endpoints
Benefits
– Avoids breaking consumer applications after new releases
– Indicates service development activity
7, 35% yes
no
13, 65%
Good examples Bad examples
Lehrstuhl Informatik 5
Twitter, delicio.us, last.fm Amazon EC2, Google Charts
(Information Systems)
Prof. Dr. M. Jarke
11
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 examples
Lehrstuhl Informatik 5
Twitter, flickr, Twilio del.icio.us, digg
(Information Systems)
Prof. Dr. M. Jarke
12
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 orchestration
Lehrstuhl Informatik 5
– Cure on the way from research, industry to support!
(Information Systems)
Prof. Dr. M. Jarke
13
14. Questions?
Contact: renzel@dbis.rwth-aachen.de
Lehrstuhl Informatik 5
(Information Systems)
Prof. Dr. M. Jarke
14