Room: Queluz III
13:00 Welcome and Introduction (Rosa Alarcon)
Session 1 - Keynote
The Brazilian industry has seen some big projects involved in a hypermedia based architecture for the past few years. But this evangelization of the industry took us somewhere between the industry usually call REST and what the academia see as REST. We will go through two projects in Brazil that have used hypermedia in different levels and talk about the issues on adopting it by small and big companies in Brazil and how those decisions have affected those companies in the last few years
Today, innovative companies are forced to evolve their software systems faster and faster, either for providing customer services and products or for supporting internal processes. At the same time, already existing, maybe even legacy systems are crucial for dierent reasons and by that cannot be abolished easily. While integrating legacy software into new systems in general is considered by well-known approaches like SOA (service-oriented architecture), at the best of our knowledge, it lacks of ways to make legacy systems available for remote clients like smart phones or embedded devices. In this paper, we propose an approach to leverage heterogeneous (legacy) applications by adding RESTful web-based interfaces in a model-driven way. We introduce an additional application layer, which encapsulates services of one or several existing applications, and provides a unified, web-based, and seamless interface. This interface is modelled in our own DSL (domain-specic language), the belonging code generator produces productive Java code. Finally, we report on a case study proving our concept by means of an e-bike sharing service.
Hypermedia links and controls drive the Web by transforming information into affordances through which users can choose actions. However, publishers of information cannot predict what actions their users might want to perform and therefore, hypermedia can only serve as the engine of application state to the extent the user’s intentions align with those envisioned by the publisher. In this paper, we introduce distributed affordance, a concept and architecture that extends application state to the entire Web. It combines information inside the representation and knowledge of action providers to generate affordance from the user’s perspective. Unlike similar approaches such as Web Intents, distributed affordance scales both in the number of actions and the number of action providers, because it is resource-oriented instead of action-oriented. A proof-of-concept shows that distributed affordance is a feasible strategy on today’s Web.
REST principles define services as resources that can be manipulated by a set of well-known methods. The same definition is suitable to define service descriptions as resources. In this paper, we try to unify the two concepts (services and their descriptions) by proposing a set of best practices to build self-descriptive RESTful services accessible by both humans and machines. Moreover, to make those practices usable with little manual effort, we provide a software framework that extracts compliant descriptions from documents available on the Web, and makes them available to clients as resources.
Creating truly RESTful Web APIs is still more an art than a science. Developers have to struggle with a number of complex design decisions because concrete guidelines and processes are missing. Consequently, often they decide to implement the simplest solution which is, most of the time, to rely on out-of-band contracts between the client and the server. Instead of properly modeling the application domain, they put all their effort in the design of proprietary JSON structures and URLs. This then forms the base for the contract which is communicated in natural-language with all its ambiguity to client developers. Needless to say, that it is the server who owns the contract and thus may decide to change it at any point which more often than not results in broken clients. In this work we present a novel domain-driven approach to design Web APIs as a first step to address these issues. We discuss a number of design decisions and present concrete recommendations.