The fallacy of the multi-API culture. Conceptual and practical benefits of Representational State Transfer (REST)
| DOI | https://doi.org/10.1108/JD-07-2013-0098 |
| Pages | 233-252 |
| Date | 09 March 2015 |
| Published date | 09 March 2015 |
| Author | Ruben Verborgh,Seth van Hooland,Aaron Straup Cope,Sebastian Chan,Erik Mannens,Rik Van de Walle |
| Subject Matter | Library & information science,Records management & preservation,Document management |
The fallacy of the
multi-API culture
Conceptual and practical benefits of
Representational State Transfer (REST)
Ruben Verborgh
iMinds, Multimedia Lab, Ghent University, Ghent, Belgium
Seth van Hooland
Information and Communication Science Department,
Université Libre de Bruxelles, Brussels, Belgium
Aaron Straup Cope and Sebastian Chan
Cooper-Hewitt National Design Museum, New York, New York, USA, and
Erik Mannens and Rik Van de Walle
iMinds, Multimedia Lab, Ghent University, Ghent, Belgium
Abstract
Purpose –The purpose of this paper is to revisit a decade after its conception the Representational
State Transfer (REST) architectural style and analyzes its relevance to address current challenges from
the Library and Information Science (LIS) discipline.
Design/methodology/approach –Conceptual aspects of REST are reviewed and a generic
architecture to support REST is presented. The relevance of the architecture is demonstrated with
the help of a case study based on the collection registration database of the Cooper-Hewitt National
Design Museum.
Findings –The authors arguethat the “resources and representations”model of REST is a sustainable
way for the management of webresources in a context of constant technological evolutions.
Practical implications –When making information resources available on the web, a resource-oriented
publishing model can avoid the costs associated with the creation of multiple interfaces.
Originality/value –This paper re-examines the conceptual merits of REST and translates the architecture
into actionable recommendations for institutions that publish resources.
Keywords Web applications, Information architecture, Hypermedia, REST, Uniform interface,
Web APIs
Paper type Research paper
1. Introduction
1.1 General context
“We shall be questioning concerning technology, and in so doing we should like to
prepare a free relationship to it.”With this agenda in mind, Heidegger opens his 1954
essay on the essence of technology and humanity’s deeply entangled relation with it
(Heidegger, 1954). Interpretations of this essay notoriously vary, but his key mes sage is
to raise awareness regarding our inability to step outside technological thinking. With
this message, Heidegger is often mistaken for a Luddite, but there is tremendous value
Journal of Documentation
Vol. 71 No. 2, 2015
pp. 233-252
©Emerald Group Publis hing Limited
0022-0418
DOI 10.1108/JD-07-2013-0098
Received 23 July 2013
Revised18February2014
Accepted 25 February 2014
The current issue and full text archive of this journal is available on Emerald Insight at:
www.emeraldinsight.com/0022-0418.htm
The described research activities were funded by Ghent University, the Institute for the
Promotion of Innovation by Science and Technology in Flanders (IWT), the Fund for Scientific
Research Flanders (FWO Flanders), and the European Union.
233
The fallacy of
the multi-API
culture
in the quest to see technology for what it really represents. By doing so, we can try to
manage its impact on our lives.
Much of the same thinking underpins the introduction of Roy T. Fielding’s (2000)
doctoral thesis, which formalized the concept of the Representational State Transfer
(REST) architectural style for distributed hypermedia systems such as the web.
Fielding criticizes in his introduction the “design-by-buzzword”context in which web
applications are developed. In a distributed network such as the internet, innovation
through fast-paced technological changes comes at a cost. The expense of adaptation
considerably drives up the costs of our information industry.
More than a decade later, the desire for new applications continues to grow, particularly
for rich web applications and mobile applications (Kroski, 2008). The re-use of web content
in these contexts requires an automated access to the content in a more rigidly structured
format than HyperText Markup Language (HTML), such as for example JavaScript Object
Notation ( JSON) (Severance, 2012). If the incentives are important enough, the owner of the
web content typically investsindevelopingaWebAPIthatrepliesintheJSONformat.
A Web API or Web Application Programming Interface is a set of protocol constructs
offered by a web application through which third-party web or software applications can
interact with it. It typically has a large functional overlap with the possibilities offered to
visitors offered by the web site, but a Web API makes those available to pieces of software
as well, such as JavaScript components on an internal or external web site, mobile
applications, desktop applications, and others. A related concept is Web service, which
predates the term “Web API”, and refers to a means to enable programming over the web.
In practice, definitions notoriously vary; however, “Web services”have come to stand for
heavy-weight, enterprise, Extensible Markup Language (XML)-messaging-based solutions,
whereas “Web APIs”are more light-weight and targeted at web and mobile applications.
Interestingly, a Web API often does not offer new functionality in addition to the HTML
version; it mostly provides the same content and actions, but makes them available in
another format. The logical consequence of building new APIs in response to changing
requirements is that a separate API will be necessary for each and every purpose. If, for
example, a web site wants to make content available in Resource Description Framework
(RDF), it would also need an RDF API next to the existing HTML and JSON APIs.
Additionally, to meet social network demands, it might also need special APIs, and may be
even others for specific device types. In the end,themultiplicationofAPIsresultsinaweb
site’s content being scattered across applications which all need to be maintained separately.
Uniform Resource Locators (URLs) can serve as a window to observe the fast-
evolving and hype-driven environment. The multi-API culture has manifested itself
over the years in the appearance of implementational details within URLs. For instance,
imagine a URL containing/showObject.php?id ¼3685. The presence
of showObject points to a specific script and php indicates the use of a specific
technology. In the short term, these characteristics are not necessarily problematic as
the URL fulfills the function of uniquely identifying a resource. However, if we allow
the underlying technology to influence the naming scheme, each change in technology
can possibly change the URL which serves to identify a resource. This concrete
example is a painful illustration of the need to decouple as much as possible the
identification of resources and the concrete technologies used to manage them.
1.2 Relevance to the Library and Information Science (LIS) discipline and research question
Even though REST has been primarily discussed within the computer science domain
(Khare and Taylor, 2004; Pautasso et al., 2008; Vinoski, 2007; Zuzak and Schreier, 2012),
234
JDOC
71,2
To continue reading
Request your trial