REST: Advanced Research Topics and Practical Applications

Decentralized systems are systems-of-systems whose services are governed by two or more separate organizations under distinct spheres of authority. Coordinated evolution of the various elements of a decentralized system may be difficult, if not impossible, as individual organizations evolve their service offerings in response to organization- and service-specific pressures, including market demand, technology, competitive and cooperative interests, and funding. Consequently, decentralized services offer unique challenges for evolution and adaptation that reach well beyond any one single organizational boundary. Client-driven service customization and tailoring is a powerful tool for meeting conflicting, independent client demands in an environment where disorderly and uneven service evolution predominates. COmputAtional State Transfer (COAST) relies on capability security to minimize the risks of client-driven customization, for which fine-grain management of communication capability is critical. We introduce the Capability URL (CURL) as the unit of communication capability and show how two distinct mechanisms, communication capability and mobile code, can be combined to express and enforce constraints on the communications among decentralized computations.

Recent advancements in terms of protocols and architectural design, bring us closer to realize the Internet of Things (IoT)/Web of Things (WoT) vision; with disruptive effects on the interaction between humans and reality. We detail the specific embedded devices requirements, highlighting how and whether the RESTful principles are able to satisfy them or should eventually evolve. We also analyze the current approaches undertaken by the Internet and resource-constrained environment’s protocols, to cover such requirements. In particular, the Constrained Application Protocol (CoAP) aims at enabling direct RESTful access to Internet-connected devices. We discuss its features and limitations, referring to the emerging problematic scenario of heterogeneous networks where HTTP, CoAP, and ad-hoc networks are interconnected. Common everyday embedded devices enter these sensor networks, as part of a global digital nervous system where everything can be measured, thus giving more control to the people over their own surroundings.

This chapter describes the REST observer, a generic observation and notification framework that allows web clients to receive real-time events about state changes in resources of interest.

The REST architectural style assumes that client and server form a contract with content negotiation, not only on the data format but implicitly also on the semantics of the communicated data, i.e., an agreement on how the data have to be interpreted [247]. In different application scenarios such an agreement requires vendor-specific content types for the individual services to convey the meaning of the communicated data. The idea behind vendor-specific content types is that service providers can reuse content types and service consumers can make use of specific processors for the individual content types. In practice however, we see that many RESTful APIs on the Web simply make use of standard non-specific content types, e.g., text/xml or application/json [150]. Since the agreement on the semantics is only implicit, programmers developing client applications have to manually gain a deep understanding of several APIs from multiple providers.

The ecosystem of services on the Web continues to grow and evolve while, at the same time, the number and diversity of connected devices increases; challenges lie ahead for both providers and consumers of Web services. This chapter represents a “what-if” proposal; an alternate paradigm for dealing with an increasingly growing and heterogeneous network. Drawing from diverse sources including physical architecture, industrial design, the psychology of perception, and cross-cultural mono-myth, a new implementation paradigm is proposed to help software architects and developers meet these challenges; one that invites participants to shift their mental model from that of programming network devices to programming the network to which those devices are connected. To accomplish this goal an “affordance-rich message” is proposed; one that is based on shared understanding through network-oriented affordances instead of device-oriented APIs. A working model based on this approach is covered, examples given, and areas of related work identified.

In this chapter we will illustrate how Linked Data can be used to create loosely coupled, hypermedia-driven Web APIs. Apart from introducing JSON-LD and showing how it can be used as a generic data format for Web APIs, we will demonstrate how a short list of concrete design guidelines and a small vocabulary can be used to create APIs that expose enough information to be usable by a completely generic API browser. Based on a simple prototype, we will show how easily such a, at first sight, disruptive approach can be integrated in current Web frameworks and how it can be used to build interoperable and evolvable APIs in considerably less time. Last but not least, we will give an outlook of how such an approach opens the door to other Semantic Web technologies.

In the last decade the paradigm of service-oriented computing is gaining more and more space in industry and academia in order to improve the communication among different information systems that exist in a corporate environment. Due to recent advances of so-called “Web 2.0”, a new architectural style called Web Oriented Architecture (WOA) was proposed in order to ensure a simple way to connect IT (Information Technology) components dynamically. The new architectural style describes the use of RESTful Web services as one of its principles in order to achieve a functional interface simple and uniform. This chapter will discuss the use of the paradigm of Model Driven Development in the construction of RESTful web services, presenting a domain-specific language (DSL) capable of representing the static characteristics and behavior of these services, enabling the generation of source code in an automated manner.

A very common form of collaborative work involves people working on shared resources. Consider for example the process of co-producing a project report, where a content editor writes the text, a librarian cross-references the text against a repository of citations, and an accountant validates the budget line items against applicable rules; or the process of reviewing a loan application where someone examines the credit history of the applicant and co-signatories and a risk-assessment specialist makes the final decisions based on these histories and the bank’s policies. All these types of collaborative work share a few key properties. The various process steps are partially ordered, based on logical inter-dependencies among them. Although some steps may be automated, the process is driven primarily by people using interactive tools, who somehow notify each other about their progress. Finally, these processes usually take a long time to complete. Web-based collaboration is the norm nowadays. Collaborative editors, such as wikis for example, coordinate people working on documents, but are neither powerful enough to support coordination more complex than notifications, nor amenable to integration with other tools. On the other end of the spectrum, classic business-process management systems are powerful enough to cover complex coordination requirements, but are too complicated to use and too regimented in the types of coordination they support. As information is becoming increasingly available and shared through REST APIs, there is a need for enabling web-based collaborative systems to support resource-centric collaborations. To meet the need for flexibly coordinating people, interactive tools, and automated services, we have developed a coordination approach and a supporting framework. Our solution consists of (a) a language and tool support for specifying collaborative activities and the resources they manipulate, (b) an engine for enacting them at run time, and (c) a systematic methodology for integrating the engine with the various interactive systems and services involved. Our framework balances expressiveness and simplicity and its usefulness has been demonstrated in a real-world project.

Abril Mídia is one of the largest media companies in Brazil. In 2011 it published 52 titles and is a leader in 22 out of 26 segments in which it operates. In the digital world, the big challenge Abril faces is deliver a large volume of information that it generates in a high diversity of digital channels, such as websites, mobile sites and TVs. The chosen solution was the building of a distributed platform, named Alexandria, that allows the content to be added and handled by separated information domains, implemented with REST constraints and with a hypermedia API, that is exposed to publishers and end users. This present chapter explains how we built the platform, and the lessons learned in this process.

Although REST is usually defined as an architectural style for distributed applications, we show how REST principles were adapted to in-process use for a feed processing application generating significant parts of the BBC Sport website and Ceefax (Videotext) output. The simplicity of the resulting system led to significant improvements in reliability, performance, capability and maintainability over the predecessor system, despite the fact that the external (legacy) interfaces were not RESTful. We believe this example shows that REST-like interfaces do not have be constrained to exist exclusively at process boundaries, and conversely that process-internal APIs can benefit from making them more REST-like.