Towards Automated Invocation of Web APIs

This paper, targeting the large variety of Web APIs, presents an approach towards automated invocation of Web APIs. This approach applies a data schema, to the SAWSDL lowering schema mapping, a grounding mechanism that connects the ontological representations of Web APIs with their execution messages. It is intuitive to existing standard efforts and effective in coping with the heterogeneities witnessed by a majority of Web APIs

Software Tool for Validation of Chromatographic Analytical Method

Tänapäeval toetuvad paljud valdkonnad erinevate ainete analüüsimiseks analüütilistele protseduuridele. Meditsiinivaldkonnas kasutatakse neid laborianalüüside tegemiseks. Farmaatsias kasutatakse neid ravimite aktiivsete komponentide ja nende koguste määramiseks ning defektide tuvastamiseks. Toitainetööstuses määratakse nende abil toitude ja nende koostisosade omadused. Analüütilist protseduuri võib vaadelda keemilise analüüsi algoritmina. Nende protseduuride suure populaarsuse tõttu on vajalik saada neid valideerida. Valideerimine tõestab, et analüütilise protseduuri poolt kirjeldatav keemiline analüüs on antud otstarbe jaoks mõistlik: et sellega saab vajalikku ühendit piisava täpsusega mõõta. Kahjuks teostatakse protseduuride valideerimine tänapäeval käsitsi analüütiliste keemikute poolt. Käsitsi valideerides võtab aga see palju aega ja on kerge teha vigu. Seega on vajalik analüütiliste keemikute töö hõlbustamiseks luua süsteeme, mis kindlustaks tulemuse korrektsust ja teeks kogu protsessi kergemaks. Tartu Ülikooli keemia instituut on tunnistanud selliste süsteemide vajalikust ja alustas ühe sellise süsteemi - ValChrom’i - arendust. See lõputöö hindab olemasolevate lahenduste tugevaid ja nõrki külgi ning räägib analüütiliste protseduuride valideerimiseks mõeldud veebirakenduse ValChrom implementatsioonist.Many industries rely on analytical procedures to analyze various substances. In the medical field they are used to perform laboratory analyzes. In the pharmaceutical industry they are used to determine and quantify the active component of a drug product as well as impurities. In the food industry they are used to identify the properties of foods and their ingredients. An analytical procedure can be assimilable to the algorithm of a chemical analysis. Due to their widespread use, analytical procedures must be validated. The validation process will prove that the chemical analysis described by the analytical procedure is judicious and fit for its intended use case. That is, the chemical analysis can accurately measure the compound it is supposed to measure. Sadly, that validation process, currently, is performed manually by analytical chemists. The completion of analytical procedure validation manually is tedious and potentially error-prone. Therefore, accessible systems that can assist analytical chemists during analytical procedure validation should be made available to them. These systems will not only ensure the consistency of the result but also alleviate the workload of analytical chemists. The Department of Chemistry of the University of Tartu has acknowledged the need of such systems and launched the implementation of one named ValChrom. This thesis highlights the implementation details of ValChrom – a web-based application for analytical procedure validation, after evaluating the strengths and shortcomings of existing similar software solutions

Types to the rescue: verification of REST APIs Consumer Code

Tese de mestrado, Engenharia Informática (Engenharia de Software) Universidade de Lisboa, Faculdade de Ciências, 2019As arquiteturas de software são fundamentais para o desenvolvimento de um software fiável, escalável e com uma fácil manutenção. Com a criação e crescimento da internet, surgiu a necessidade de criar padrões de software que permitam trocar informação neste novo ambiente. O protocolo SOAP e a arquitetura REST são, dos padrões que emergiram, os que mais se destacaram ao nível da utilização. Durante as últimas décadas, e devido ao grande crescimento daWorld WideWeb, a arquitetura REST tem se destacado como a mais importante e utilizada pela comunidade. REST (Representational State Transfer) retira partido das características do protocolo HTTP para descrever as mensagens trocadas entre clientes e servidores. Os dados na arquitectura REST são representados por recursos, que são identificados por um identificador único (p.e. URI) e que podem ter várias representações (em vários formatos), que são os dados concretos de um recurso. A interação com os recursos é feita usando os métodos HTTP: get para obter um recurso, post para adicionar um novo recurso, put para fazer uma atualização de um recurso, delete para remover um recurso; entre outros, sendo estes os principais para aplicações CRUD. As aplicações RESTful, isto é, aplicações que fornecem os seus serviços através da arquitetura REST, devem ser claras na especificação dos seus serviços de forma a que os seus clientes possam utilizá-las sem erros. Para tal, existem várias linguagens de especificação de APIs REST, como a Open API Specification ou a API Blueprint, no qual é possível descrever formalmente as várias operações fornecidas pelo serviço, como o formato dos pedidos de cada operação e as respetivas respostas. No entanto, estas linguagens apresentam uma limitação nas condições formais que se pode colocar nos parâmetros dos pedidos e no impacto que estes têm no formato e conteúdo da resposta. Deste modo, foi introduzida uma nova linguagem de especificação de aplicações REST, HeadREST, onde é adicionada a expressividade necessária para cobrir as lacunas das outras linguagens. Esta expressividade é introduzida com a utilização de tipos refinados, que permitem restringir os valores de um determinado tipo. Adicionalmente, é introduzida também uma operação que permite verificar se uma determinada expressão pertence a um determinado tipo. Em HeadREST, cada operação é especificada usando uma ou mais asserções. Cada asserção é composta por um método HTTP, um URI template da operação, uma pré-condição que define as condições onde esta operação é aceite, e uma pós-condição que estabelece os resultados da operação se a pré-condição for comprida. Deste modo, estas condições permitem expressar os dados enviados nos pedidos e a receber na resposta, assim como expressar o estado do conjunto de recursos antes e depois do pedido REST. Devido à utilização de tipos refinados não é possível resolver sintaticamente a relação de subtipos na validação de uma especificação HeadREST. Deste modo, é necessária uma abordagem semântica: a relação de subtipos é transformada em fórmulas de lógica de primeira ordem, e depois é utilizado um SMT solver para resolver a formula e, consecutivamente, resolver a relação de subtipos. Por outro lado, é também importante garantir que as chamadas às APIs REST cumprem as especificações das mesmas. As linguagens de programação comuns não conseguem garantir que as chamadas a um serviço REST estão de acordo com a especificação do serviço, nomeadamente se o URL da chamada é válido e se o pedido e resposta estão bem formados ao nível dos valores enviados. Assim, um cliente só percebe se as chamadas estão bem feitas em tempo de execução. Existem poucas soluções para análise estática deste tipo de chamadas (RESType é um raro exemplo) e tendem a ser limitadas e a depender de um único tipo de linguagem de especificação. Para além disso, os clientes de serviços REST tendem a ser maioritariamente desenvolvidos em JavaScript, que possui uma fraca análise estática, o que potencializa ainda mais o problema identificado.Numa primeiro passo para tentar resolver este problema desenvolveu-se a linguagem SafeScript, que se caracteriza por ser um subconjunto do JavaScript equipado com um forte sistema de tipos. O sistema de tipos é muito expressivo graças à adição de tipos refinados e também de um operador que verifica se uma expressão pertence a um tipo. SafeScript apresenta flow typing, isto é, o tipo de uma expressão depende da sua localização no fluxo de controlo do programa. Tal como no HeadREST, não é possível realizar uma simples análise sintática para a validação de tipos. No entanto, neste caso trata-se de uma linguagem imperativa com flow typing, logo uma abordagem igual de tradução direta para um SMT solver não é trivial. Deste modo, a validação de tipos é feita traduzido o código SafeScript para a linguagem intermédia Boogie, onde as necessárias validações são traduzidas como asserções, sendo que o Boogie utiliza internamente o Z3 SMT solver para resolver semanticamente as asserções. Devido à validação semântica, o compilador de SafeScript consegue detetar estaticamente diversos erros de execução comuns, como divisão por zero ou acesso a um array fora dos seus limites, e que não conseguem ser detetados por linguagens similares, como o TypeScript. SafeScript compila para JavaScript, com o intuito de poder ser utilizado em conjunto com este. Graças ao seu expressivo sistema de tipos, o validador de programas SafeScript é também um verificador estático. A partir deste é possível provar que um programa cumpre uma determinada especificação, que pode ser descrita usando os tipos refinados. Neste trabalho destacou-se a capacidade de prova do validador de SafeScript, concretamente resolvendo alguns desafios propostos pelo Verification Benchmarks Challange. A partir do SafeScript desenvolveu-se a extensão SafeRESTScript, que adiciona pedidos REST à sintaxe do SafeScript e valida-os estaticamente de encontro a uma especificação HeadREST. Para cada chamada REST são feitas principalmente duas validações. Em primeiro lugar, é verificado se o URL é um endereço válido do serviço para o método HTTP do pedido, isto é, se existe algum triplo na especificação com o par método e URL do pedido. De seguida, e com a tradução da especificação HeadREST importada para Boogie, é verificado se as chamadas REST cumprem os triplos da especificação, nomeadamente, se as pré-condições são cumpridas então as pós-condições também se devem verificar. Por exemplo, se uma pós-condição, cuja respetiva pré-condição é verdadeira para uma determinada chamada, asserta que no corpo da resposta existe um objeto com o campo id, então um acesso a este campo no corpo da resposta é validado. Neste trabalho, como exemplo ilustrativo das capacidades da linguagem, desenvolveu-se um cliente SafeRESTScript da API REST do conhecido repositório GitHub. Ambas as linguagens possuem um compilador e editor que estão disponíveis como plug-in para o IDE Eclipse, para além de uma versão terminal. As duas linguagens possuem várias limitações, e por isso muito trabalho ainda existe pela frente. No entanto, SafeScript e SafeRESTScript não têm ambição de ser linguagens de produção, mas sim contribuir para um melhoramento da análise estática de programas e mostrar que é possível auxiliar o desenvolvimento fiável de código cliente de serviços REST.REST is the architectural sytle most used in the web to exchange data. RESTful applications must be well documented so clients can use its services without doubts and errors. There are several specification languages for describing REST APIs, e.g. Open API Specification, but they lack on expressiveness to describe the exchanged data. Head- REST specification language was introduced to address this gap, containing an expressive type system that allows to describe rigorously the request and response formats of a service endpoint. On the other hand, it is also important to ensure that REST calls in client code meet the service specification. This challenge is even more important taking in account that most REST clients are made in JavaScript, a weakly typed language. To aim this problem, we firstly developed SafeScript, a subset of JavaScript equipped with a strong type system. SafeScript has a expressive type system thanks to refinement types and to an operator that checks if an expression belongs to a type. A semantic subtyping analysis is necessary; the typing validation in done by translating the code to Boogie intermediate language which uses the Z3 SMT solver for the semantic evaluation. SafeScript compiles directly to JavaScript. SafeRESTScript is an extension of SafeScript that adds REST calls, being a client-side language for consuming REST services. It uses HeadREST specifications to verify REST calls: whether the URL of the call is a valid endpoint and whether the data exchanged match the pre and post-conditions declared in the specification. With the creation of this new languages, we dot not intend in having them as production languages, but to show that it is possible to contribute with a better verification and correction in area where software reliability is weak

Automatic tests generation for Restful Apis

Tese de mestrado, Engenharia Informática (Engenharia de Software), Universidade de Lisboa, Faculdade de Ciências, 2017A programação de serviços web que fornecem interfaces aplicacionais que seguem os princípios do estilo arquitetural REST (Representational State Transfer) [38], designadas em inglês por RESTful APIs, e de aplicações cliente deste tipo de serviços é actualmente muito popular [63]. Por exemplo, aplicações como Twitter, Instagram, Youtube, Uber e Gitlab, fornecem acesso programático às suas aplicações cliente através deste tipo de APIs (Application Programming Interfaces). Isto acontece porque o uso deste tipo de APIs, quando comparado com as tradicionais interfaces de serviços web baseados em SOAP (Simple Object Access Protocol), simplificam grandemente o desenvolvimento das aplicações cliente. Mais recentemente, com o advento da arquitetura baseada em microserviços, o desenho de aplicações como conjuntos de serviços tornou-se muito comum, alavancando ainda mais a utilização das APIs REST [35]. O desenvolvimento eficaz de aplicações cliente deste tipo de serviços exige que as suas interfaces estejam bem documentadas. Apesar de iniciativas importantes como a Open API Specification [11], focadas na criação e promoção de um formato aberto para a descrição de APIs REST, o suporte à descrição deste tipo de APIs é atualmente extremamente limitado e incide, sobretudo, na estrutura e representações dos dados trocados entre clientes e fornecedores. De forma a ultrapassar as limitações existentes e suportar também a descrição de aspetos semânticos subjacentes às APIs REST, desenhámos e implementámos a linguagem HEADREST que permite especificar cada um dos seus serviços individualmente, num estilo reminescente dos triplos de Hoare [50], os quais designamos simplesmente por asserções e utilizando tipos de refinamento [45]. HEADREST é uma linguagem que inclui elementos para superar as limitações das abordagens existentes. O objetivo de HEADREST não é estender a Open API Specification, mas antes identificar primitivas que permitam aumentar o seu poder expressivo e demonstrar que é possível explorar estas descrições para avançar o estado da arte no que diz respeito à programação e testes de APIs REST. Normalmente, as regras de negócio de APIs REST esperam que os seus clientes enviem valores que respeitem alguma expressão lógica, por exemplo, um número de contribuinte. De forma a suportar esse requisito, HEADREST suporta tipos de refinamento que refinem um tipo base (booleano, inteiro, string ou array) perante uma fórmula. Em APIs REST, o estado da API consiste no conjunto de recursos que existem em algum instante temporal. Assim sendo, as asserções subdividem-se em um método (a ação a realizar), um URI (Uniform Resource Identifier) Template [46], uma pré-condição e uma pós-condição. Enquanto que a pré-condição especifica o estado no qual a asserção é válida, além de refinar os dados a enviar no pedido para a API, a pós-condição especifica o estado resultante da execução do pedido enviado e os dados de resposta produzidos pela API. Uma asserção descreve então que se um pedido para a execução de uma certa ação (por exemplo, POST [39]) sobre uma expansão do URI Template da asserção inclui dados que satisfazem a pré-condição, sendo que a ação é desenrolada num estado que satisfaz a pré-condição, então a resposta e o estado resultante satisfazem a pós-condição. De forma a descrever um estado esperado da API são usadas variáveis de recurso que representam recursos de um certo tipo. Usando estas variáveis de recurso e quantificadores existenciais ou universais é possível escrever as pré-condições ou pós-condições que descrevem o estado esperado. No geral, HEADREST suporta expressões lógicas, aritméticas e relacionais, predicados sobre arrays, além de acesso a propriedades de objetos bem como de entradas de arrays e, um predicado para verificar se uma dada string está no universo de uma expressão regular. Através do uso continuado de HEADREST, usando um estudo de caso desenvolvido para suportar o presente trabalho, foram adicionados construtores derivados da sintaxe base que reduzem a quantidade de código a escrever, bem como os potenciais erros subjacentes. De forma a facilitar a especificação de APIs REST em HEADREST desenvolvemos um plug-in para o Eclipse de modo a permitir a validação sintáctica e semântica. A implementação da linguagem foi feita utilizando a framework Xtext que permite o desenvolvimento de novas linguagens e plug-ins para o Eclipse. Podemos dividir a implementação em três partes: escrita da gramática, implementação de um mecanismo para verificar se todas variáveis de uma especificação estão devidamente declaradas e implementação do sistema de tipos. O nosso sistema de tipos é bidirecional, existindo duas relações de tipificação: uma de verificação de tipos; e outra de síntese de tipos. A verificação se um dado tipo é subtipo de outro tipo é feita de forma semântica [43] recorrendo a um SMT (Satisfiability Modulo Theories), nomeadamente Z3 [32]. Para tal baseamo-nos no trabalho de Bierman et al. [26], sendo que modificámos a axiomatização para o Z3 apresentada nesse trabalho de forma a contemplar os construtores da nossa linguagem. No futuro, espera-se conseguir gerar stubs servidor e SDKs (Software Development Kits) cliente a partir de especificações descritas usando HEADREST e verificar estaticamente código cliente e servidor de encontro a especificações HEADREST. Além disso, pretende-se integrar na linguagem questões de segurança em contexto REST, nomeadamente em termos de autenticação e de confidencialidade. Um dos usos possíveis desta linguagem é a geração e execução automática de testes. Para tal explorámos duas metodologias de testes diferentes. Ambas as metodologias apresentam como ponto comum a avaliação de uma asserção que é feita através do uso do Z3 para gerar pedidos que satisfaçam a pré-condição e inclui a verificação da pós-condição a partir da resposta obtida. A primeira metodologia envolve construir uma árvore de classificação [47] para cada asserção da especificação e usando um critério de cobertura, atualmente Minimum Coverage, gerar variações da pré-condição da asserção em questão. Estas variações exploram mudanças de certos elementos da linguagem (por exemplo, disjunções) tentando manter a satisfiabilidade da expressão. Por exemplo, uma disjunção e1 V e2 pode ser substituída por uma de três formas alternativas: e1 ^ e2, ¬e1 ^ e2 ou e1 ^ ¬e2. Esta metodologia exige que o testador especifique para cada caso de teste gerado o contexto no qual a nova asserção é satisfazível. Esse contexto é composto por uma sequência de outras asserções da especificação que são avaliadas antes de avaliar a própria asserção. A segunda metodologia tenta avaliar uma sequência aleatória de asserções de tamanho N. Para tal, a cada momento uma asserção é escolhida do conjunto de asserções da especificação. De forma a melhorar esta seleção pontuamos cada asserção é escolhida asserção que possua uma maior pontuação cuja pré-condição seja satisfazível. Repetimos este procedimento N vezes, podendo ainda repetir o algoritmo completo M vezes. A pontuação dada às asserções considera se uma dada asserção já foi avaliada alguma vez (Assertion Coverage), se um dado par de asserções, que finaliza na asserção em questão, já foi avaliado de forma consecutiva (Assertion Pair Coverage), o impacto que o método da asserção tem sobre a API (por exemplo, um POST bem sucedido tem maior impacto do que um POST mal sucedido). Em caso de empate, as asserções em questão são ordenadas de forma aleatória, sendo que é possível especificar a semente do gerador de números aleatórios de forma a que o teste de sequência seja determinista, podendo ser repetido mais tarde. Além disso, incluímos ainda um algoritmo adaptado do trabalho de Chakrabarti et al. [30] que verifica se uma dada API respeita a restrição do REST Hypermedia As The Engine of Application State. Este algoritmo pode ser executado após a avaliação de qualquer asserção, sendo que quando usado em conjunção com o teste de sequência permite identificar operações que fazem com que a API deixe de respeitar esse princípio. Da avaliação à primeira metodologia concluiu-se que esta tem o potencial de produzir um número elevado de casos de testes, apesar de que o testador tem de indicar para cada um desses casos de teste uma lista de asserções que devem ser avaliadas antes de avaliar o caso de teste propriamente dito. Da metodologia de teste da sequência aleatória de asserções concluiu-se que o uso de uma função que pontua asserções a cada instante da sequência conduz sempre a melhores resultados, podendo revelar até 101% mais cobertura ao nível de asserções ou pares de asserções, do que se for apenas usada uma ordenação aleatória das asserções. Além disso, através da função de pontuação obtivemos para o estudo de caso 99.27% de cobertura de pares de asserções enquanto que para as mesmas condições, a versão sem a função de pontuação apenas obteve 56.16%.The programming of web services that provide APIs (Application Programming Interfaces) that adhere to the REST (Representational State Transfer) architectural style is nowadays extremely popular. For instance, applications like Gitlab and Youtube, provide programmatic access to their client applications through this type of APIs. The main reason for this is that traditional alternatives like SOAP (Simple Object Access Protocol) revealed an increased complexity when compared to REST. The effective development of client applications that use RESTful API require that their interfaces must be well documented. There are several languages that tackle this question but rarely solve it at a semantic level. Even those are unable to express complex business rules. This work presents a new language based on Hoare triples (an assertion) and refinement types to precisely express complex business rules through logical expressions as well as to express the relations between requests and responses. Using this language we implemented a testing tool that makes available two testing methodologies. The first builds a Classification Tree based on the precondition of an assertion and generates tests cases from that. The tester adds context information necessary to initialize the server state under which the precondition is satisfiable. The second tests an API using random sequences of tests that adaptively choose an assertion among several candidates in such a way that the coverage of individual assertions and pairs of assertions is higher than pure random sequence testing. The evaluation concluded that the first has the potential of generating a high number of test cases, however the work effort of the tester is also high. In terms of the second, in our study case, we found that adaptively choosing assertions may lead up to 101% more coverage than randomly choosing assertions. Also, the adaptive version achieved 99.27% of coverage of pairs of assertions against 56.16% of coverage obtained with the pure random version