Application Programming Interfaces (APIs) are an important component in modern-day web applications. Representation State Transfer (REST) has been the de facto standard for building web APIs since its inception in 2000. In 2015 Facebook launched GraphQL, a technology with the purpose of solving some of the drawbacks of traditional REST APIs. However, few scientific studies have yet to assess the benefits and drawbacks of GraphQL vs REST from a performance standpoint. In this study, a controlled experiment was conducted to assess three categories of runtime performance: response time, CPU consumption and memory consumption. Results show that GraphQL consumes more server-side resources than REST, except in certain scenarios, while response time depends highly on the query. When fetching the same amount of data, REST is more efficient than GraphQL in every regard.  Keywords: Web Development, Application Programming Interfaces, REST, GraphQL, Performance.

[pt] Um cenário comum atualmente é o de aplicações desenvolvidas usando duas linguagens de programação a fim de otimizar partes onde o desempenho é crítico e permitir extensibilidade através de scripts escritos pelo usuário. Há várias formas de se obter esse tipo de interoperabilidade; idealmente, entretanto, uma linguagem deve prover uma interface de acesso externo (foreign language interface, FLI) que permita ao programador receber e enviar tanto chamadas como dados para outra linguagem. Este trabalho discute as principais questões envolvendo o projeto de APIs para integração de ambientes de execução de linguagens em aplicações C. Apresentamos os principais problemas enfrentados na interação entre código executando em um ambiente com características inerentemente dinâmicas como o de uma linguagem de script com código C. Comparamos aqui as abordagens empregadas por cinco linguagens no tratamento da comunicação entre os espaços de dados de C e do ambiente de execução embutido e as conseqüências destas abordagens no gerenciamento de memória, bem como no compartilhamento de código entre a aplicação C e o da linguagem de script. Ilustramos as diferenças das APIs destas linguagens e o impacto destas no código resultante de uma aplicação C através de um estudo de caso. Diferentes linguagens de script são embutidas como plugins de uma mesma biblioteca, que por sua vez expõe a aplicações clientes uma API genérica de scripting. Assim, o código de cada plugin permite observar de forma clara e isolada os procedimentos adotados em cada linguagem para chamada de funções, registro de funçoes C e conversão de dados entre os ambientes. / [en] Applications written in two programming languages, in order to optimize parts where performance is critical or to obtain extensibility through userwritten scripts, are commonplace nowadays. There are several ways to obtain this kind of interoperability; ideally, however, a language should provide a foreign language interface (FLI), allowing the programmer to send and receive both data and function calls to the external language. This work discusses the main issues involving the design of APIs for the integration of language environments within C applications. We present the main problems faced in the interaction between code executed in an environment with inherently dynamic characteristics such as a scripting language and C code. We compare the approaches employed by five languages when handling communication between the data spaces of C and the embedded runtime environment and the consequences of these approaches in memory management, as well as sharing of code between the C application and that from the scripting language. We illustrate the differences of the APIs of those languages and their impact in the resulting code of a C application through a case study. Different scripting languages were embedded as plugins for a library, which on its turn exposes to client applications a generic scripting API. This way, the code of each plugin allows us to observe in a clear and isolated way the procedures adopted by each language for function calls, registration of C functions and conversion of data between the environments.

The aim of the study was to develop a platform to monitor and evaluate care homes using heterogeneous data sources for a French startup company. The study found that there was no current system to supervise healthcare resources in these facilities with live data. To address this, a digital platform was proposed that would integrate information from various sources, including IoT devices, existing software systems and digital documents. The proposed platform, which would be built from scratch, includes a data collection and processing system, and a blockchain to store the processed data. The platform would also include a dashboard with features, Key Performance Indicators (KPIs), and graphs for stakeholders to access.   The research would focus on the first two objectives of the proposed platform, which are design a platform for real time access to heterogeneous data sources and generate derivative dataset (generate transformed data set from the primary raw data set) with access but not visibility of the accessible zero knowledge heterogeneous data in secured way. Zero knowledge refers to fetching data from primary data sources and present it to users of in another format which can be understand easily, while hiding actual data and transforming mechanism (Goldreich, 2004). The proposed solution should be versatile and extensible to incorporate additional data sources and generate derivative datasets in a scalable manner. The study concludes that utilizing the Design Science Research Methodology (DSRM) to investigate and identify an ideal solution to the research topics is both challenging and stimulating. Additionally, the findings can be applied by other researchers working in related fields.   In summary, the proposed solution involves the development of a digital platform based on information system theories and technologies that will enrich the area of Information Systems for similar problems. The thesis will evaluate existing research on these theories and technologies and recommend the best solution by integrating the most suitable set of theories and technologies for the given problem. This will provide a practical solution for the immediate needs of the startup company and contribute to future research on similar problems.

Software components expose Application Programming Interfaces (APIs) as a means to access their functionality, and facilitate reuse. Developers use APIs supplied by programming languages to access the core data structures and algorithms that are part of the language framework. They use the APIs of third-party libraries for specialized tasks. Thus, APIs play a central role in mediating a developer's interaction with software, and the interaction between different software components. However, APIs are often large, complex and hard to navigate. They may have hundreds of classes and methods, with incomplete or obsolete documentation. They may encapsulate concurrency behaviour that the developer is unaware of. Finding the right functionality in a large API, using APIs correctly, and maintaining software that uses a constantly evolving API are challenges that every developer runs into. In this thesis, we design automated techniques to address two problems pertaining to APIs (1) Concurrency analysis of APIs, and (2) API mining. Speci cally, we consider the concurrency analysis of asynchronous APIs, and mining of math APIs to infer the functional behaviour of API methods. The problem of concurrency bugs such as race conditions and deadlocks has been well studied for multi-threaded programs. However, developers have been eschewing a pure multi-threaded programming model in favour of asynchronous programming models supported by asynchronous APIs. Asynchronous programs and multi-threaded programs have different semantics, due to which existing techniques to analyze the latter cannot detect bugs present in programs that use asynchronous APIs. This thesis addresses the problem of concurrency analysis of programs that use asynchronous APIs in an end-to-end fashion. We give operational semantics for important classes of asynchronous and event-driven systems. The semantics are designed by carefully studying real software and serve to clarify subtleties in scheduling. We use the semantics to inform the design of novel algorithms to find races and deadlocks. We implement the algorithms in tools, and show their effectiveness by finding serious bugs in popular open-source software. To begin with, we consider APIs for asynchronous event-driven systems supporting pro-grammatic event loops. Here, event handlers can spin event loops programmatically in addition to the runtime's default event loop. This concurrency idiom is supported by important classes of APIs including GUI, web browser, and OS APIs. Programs that use these APIs are prone to interference between a handler that is spinning an event loop and another handler that runs inside the loop. We present the first happens-before based race detection technique for such programs. Next, we consider the asynchronous programming model of modern languages like C]. In spite of providing primitives for the disciplined use of asynchrony, C] programs can deadlock because of incorrect use of blocking APIs along with non-blocking (asynchronous) APIs. We present the rst deadlock detection technique for asynchronous C] programs. We formulate necessary conditions for deadlock using a novel program representation that represents procedures and continuations, control ow between them and the threads on which they may be scheduled. We design a static analysis to construct the pro-gram representation and use it to identify deadlocks. Our ideas have resulted in research tools with practical impact. Sparse Racer, our tool to detect races, found 13 previously unknown use-after-free bugs in KDE Linux applications. Dead Wait, our deadlock detector, found 43 previously unknown deadlocks in asynchronous C] libraries. Developers have fixed 43 of these races and deadlocks, indicating that our techniques are useful in practice to detect bugs that developers consider worth fixing. Using large APIs effectively entails finding the right functionality and calling the methods that implement it correctly, possibly composing many API elements. Automatically infer-ring the information required to do this is a challenge that has attracted the attention of the research community. In response, the community has introduced many techniques to mine APIs and produce information ranging from usage examples and patterns, to protocols governing the API method calling sequences. We show how to mine unit tests to match API methods to their functional behaviour, for the specific but important class of math APIs. Math APIs are at the heart of many application domains ranging from machine learning to scientific computations, and are supplied by many competing libraries. In contrast to obtaining usage examples or identifying correct call sequences, the challenge in this domain is to infer API methods required to perform a particular mathematical computation, and to compose them correctly. We let developers specify mathematical computations naturally, as a math expression in the notation of interpreted languages (such as Matlab). Our unit test mining technique maps subexpressions to math API methods such that the method's functional behaviour matches the subexpression's executable semantics, as defined by the interpreter. We apply our technique, called MathFinder, to math API discovery and migration, and validate it in a user study. Developers who used MathFinder nished their programming tasks twice as fast as their counterparts who used the usual techniques like web and code search, and IDE code completion. We also demonstrate the use of MathFinder to assist in the migration of Weka, a popular machine learning library, to a different linear algebra library.

[pt] APIs (do inglês - application programming interfaces) desempenham um papel crucial no desenvolvimento de software. Quase todos os programadores estão frequentemente na posição de utilizar APIs de terceiros. Atualmente, encontramos várias pesquisas que procuram explorar e compreender as interações dos usuários com a API do ponto de vista da usabilidade. No entanto, tais estudos deixam de fora um aspecto importante da qualidade de uso de uma API, a comunicabilidade. Ao contrário da usabilidade, cuja definição está associada à facilidade de uso e aprendizagem, a comunicabilidade está associada à capacidade de um artefato de comunicar sua lógica de projeto. Uma API que carece de comunicabilidade pode levar os usuários ao uso indevido e produzir bugs em seu código. Esta tese de doutorado aborda este problema a partir de uma perspectiva de Engenharia Semiótica. Ao caracterizar uma API como um artefato mediador da comunicabilidade, começamos nossa tese com a proposta de que as APIs deveriam ser coloquiais. Diagnosticamos em nosso primeiro estudo que os usuários, em certos casos, têm dificuldade em compreender a lógica interna de funcionamento de um API apenas olhando para suas interfaces. Neste estudo, descobrimos que as APIs muitas vezes carecem de comunicabilidade. Enquanto a usabilidade é sobre a capacidade do usuário de aprender e usar uma API, a comunicabilidade é sobre a capacidade da API de transferir a comunicação do projetista para o usuário, expondo assim sua lógica de projeto. Uma API conversacional é aquela que pode expor sua lógica interna através de suas interfaces, atendendo aos contextos pragmáticos de seus usuários. A partir deste estudo, nós nos propusemos então a definir o que é uma API conversacional na prática e a investigar quais métodos ou tecnologias seriam necessários para auxiliar os projetistas na criação de tais APIs. Nesta tese, propomos uma estrutura conceitual e um método para apoiar o projeto de APIs de conversação. Ao projetar uma API, o projetista tem em mãos três maneiras diferentes de enviar sua mensagem ao seu usuário: o código fonte, a documentação e o comportamento da API. Nossa estrutura conceitual explora como caracterizar e classificar uma API de conversação de acordo com os três tipos de mensagens da perspectiva do projetista. Nosso método de apoio ao projeto da API de conversação, que foi inspirado nos resultados e lições aprendidas de uma pesquisa-ação que realizamos, consiste em três etapas. O primeiro passo é ajudar o projetista a identificar quem são os usuários da API e suas necessidades de conversação específicas. Na segunda etapa, o método ajuda o projetista na modelagem de possíveis conversas de API com os diferentes usuários mapeados para atingir seus objetivos. Finalmente, o método fornece um conjunto de diretrizes para guiar o projetista na definição das interfaces API, incluindo sua parametrização. Usando este método, realizamos um estudo de caso com um projeto de API, que visa apoiar a refatoração de programas Java. Do ponto de vista do projetista da API, o método o ajudou a criar empatia com seus usuários e a melhor derivar e refletir sobre os requisitos e conversas que a API deve fornecer aos diferentes perfis de usuários. / [en] APIs (application programming interfaces) play a crucial role in software development. Almost any programmer is often at the position of using thirdparty APIs. Currently, we find several researches that seek to explore and understand users interactions with the API from an usability point of view. However, such studies leave out an important aspect of an API quality of use, the communicability. Unlike usability, whose definition is associated with ease of use and learning, communicability is associated with an artifact s ability to communicate its design logic. An API that lacks communicability can lead users to misuse and produce bugs in their code. This doctoral thesis addresses this problem from a Semiotic Engineering perspective. By characterizing an API as a mediating artifact for communicability, we started our thesis with the proposal that APIs should be conversational. We diagnosed in our first study that users, in certain cases, have difficulty in understanding the internal operating logic of an API just by looking at its interfaces. In this study, we found that APIs often lack in communicability. While usability is about the user s ability to learn and use an API, communicability is about the API s ability to transfer the designer communication to the user, thus exposing its design rationale. A conversational API is the one that can expose its internal logic through its interfaces, attending the pragmatic contexts of its users. From this study, we then set out to define what a conversational API is in practice and to investigate what methods or technologies would be needed to assist designers in creating such APIs. In this thesis, we propose a conceptual framework and a method to support the design of conversational APIs. When designing an API, the designer has in hands three different ways to send his message to his user: the source code, the documentation, and the behavior of the API. Our conceptual framework explores how to characterize and classify a conversational API according to the three types of messages from the designer s perspective. Our method of supporting conversational API design, which was inspired by the results and lessons learned from an action-research we conducted, consists of three steps. The first step is to help the designer on identifying who the API users are and their specific conversational needs. In the second step, the method helps the designer on modeling possible API conversations with the different mapped users to achieve their goals. Finally, the method provides a set of guidelines to guide the designer in defining the API interfaces, including their parameterization. Using this method, we perform a case study with an API design, which aims at supporting the refactoring of Java programs. From the API designer s point of view, the method helped him on creating empathy with his users and better deriving and reflecting upon the requirements and conversations that the API should provide to the different user profiles.