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

Lehrstuhl Informatik 5(Information Systems)

Prof. Dr. M. Jarke1 These presentation slides by Dominik Renzel are licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Today’s Top “RESTful” Services and Why They Aren’t RESTful

Dominik Renzel, Patrick Schlebusch, Ralf KlammaRWTH Aachen University

Advanced Community Information Systems (ACIS)Aachen, Germany

[email protected]

The 13th International Conference on Web Information Systems Engineering (WISE 2012)November 28th-30th, 2012Paphos, Cyprus.

http://creativecommons.org/licenses/by-sa/3.0/





mailto:[email protected]



http://dbis.rwth-aachen.de/cms/research/MiCIS



Prof. Dr. M. Jarke2

Responsive Open

Community Information

Systems

Community Visualization

and Simulation

Community Analytics

Community Support

Web A

nalytics

Web

Eng

inee

ring

Advanced Community Information Systems (ACIS)

Requirements Engineering




Prof. Dr. M. Jarke3

Motivation

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

Great! Aren‘t we happy? Well, partially yes, but…

HELP!

Service

Service




Prof. Dr. M. Jarke4

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)

Study: How RESTful are today‘s top “RESTful“ services?




Prof. Dr. M. Jarke5

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

http://www.programmableweb.com/apis/directory/1?protocol=REST




Prof. Dr. M. Jarke6

Results Overview

Twitter

Flickr

Amazon

Product Adver

t.

Faceboo

k Grap

hebay

last.fm

del.icio.u

sTwilio

Yaho

o Ma

p

Googl

e Custo

m Se

arch

Yaho

o Placefind

er

GeoNames

Amazon

S3

Box.net

Googl

e Chart

s

Amazon

EC2

Digg

Googl

e Co

ntent/Se

arch

MediaWiki

Yaho

o Loc

al Se

arch

Formal Description

Links in Representations

Forms in Representations

Resource Types

Versioned Endpoint

Scoping Information

Parameter Sources

Meaningful HTTP Status

Use of HTTP Methods

HTTP Method Override

Format Selection




Prof. Dr. M. Jarke7

Availability of Formal Description Benefits

– Usable documentation– Better service discovery & integration

4; 20%

1; 5%

15; 75%

WSDLResponse XML SchemaNone

Good examplesAmazon, ebay, Yahoo Local Search

Bad examplesTwitter, Flickr and many more




Prof. Dr. M. Jarke8

Links in Representations Benefits

– Links as possible follow-up actions navigational help– HATEOAS as part of "uniform interface“ (Fielding 2000)

Good examplesTwilio, Google Custom Search

Bad examplesTwitter, Flickr and many more

4; 20%

16; 80%

Links usedNo Links




Prof. Dr. M. Jarke9

Forms in Representations & Parameter Sources

Benefits– Better information on structure and semantics of user input – Formal description of request construction

Good examples– Google Custom (in repr.)– Last.fm, Twilio (Both param sources)– Ebay (form-encoded params)

Bad examplesTwitter, Flickr, Digg

1; 5%

19; 95%

Forms UsedNo Forms

3; 15% 1;

5%

16; 80%

BothForm-encoded ContentQuery Parameter

Forms in Representations Parameter Sources




Prof. Dr. M. Jarke10

Number of Resource Types Benefits

– Grouping resources by functionality/semantics– Good indicator for “RPC-style disguised as RESTful“

Good examples– Twitter (multiple)– Google Custom Search (single)

Bad examples– Flickr (single overloaded)– Box.net (few overloaded)

8; 40%

7; 35%

5; 25%MultipleSingleOverloaded





Versioned Endpoints Benefits

– Avoids breaking consumer applications after new releases – Indicates service development activity

Good examplesTwitter, delicio.us, last.fm

Bad examplesAmazon EC2, Google Charts

7; 35%

13; 65%

yesno





Meaningful Usage of HTTP Methods & Status Codes

Benefits– Well-defined operational semantics for HTTP methods– Well-defined vocabulary for communicating success/problems to clients

Good examplesTwitter, flickr, Twilio

Bad examplesdel.icio.us, digg

14; 70%

6; 30%yesno

GET POST DELETE PUT0

5

10

15

20

25

BadReasonable

Meaningful Use of Methods Meaningful Use of Status Codes





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– Cure on the way from research, industry to support!





Questions?

Contact: [email protected]




Technology

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