Optimasi Pengunduhan Anime Jepang Bersubtitle Indonesia dengan Metode Restful API dan Firebase Cloud Messaging

(RESTful API / REST API merupakan penerapan dari API (Application Programming Interface). Sedangkan REST (Representional State Transfer) adalah sebuah arsitektur metode komunikasi yang menggunakan protokol HTTP untuk pertukaran data dimana metode ini sering diterapkan dalam pengembangan aplikasi. Dengan tujuannya untuk menjadikan sistem memiliki performa yang baik, cepat dan mudah untuk di kembangkan (scale) terutama dalam pertukaran dan komunikasi data. Firebase Cloud Message (FCM) adalah adalah solusi pertukaran pesan lintas platform yang dapat digunakan untuk mengirim pesan tanpa biaya. Dengan FCM, Anda dapat memberi tahu aplikasi klien bahwa pesan baru atau data lainnya tersedia untuk disinkronkan. Penelitian pengembangan system menggunakan metode Prototype, metode ini cocok digunakan untuk mengembangkan sebuah perangkat lunak yang dikembangkan kembali. Metode ini membuat sebuah rancangan kilat yang selanjutnya akan dievaluasi kembali sebelum di produksi secara benar. Hasil penelitian menunjukan bahwa Aplikasi dengan menggunakan firebase cloud message dapat membantu pengguna dalam mendapatkan kabar atau pembaruan yang sedang terjadi

Do RESTful API Design Rules Have an Impact on the Understandability of Web APIs? A Web-Based Experiment with API Descriptions

Context: Web APIs are one of the most used ways to expose application functionality on the Web, and their understandability is important for efficiently using the provided resources. While many API design rules exist, empirical evidence for the effectiveness of most rules is lacking. Objective: We therefore wanted to study 1) the impact of RESTful API design rules on understandability, 2) if rule violations are also perceived as more difficult to understand, and 3) if demographic attributes like REST-related experience have an influence on this. Method: We conducted a controlled Web-based experiment with 105 participants, from both industry and academia and with different levels of experience. Based on a hybrid between a crossover and a between-subjects design, we studied 12 design rules using API snippets in two complementary versions: one that adhered to a "rule" and one that was a "violation" of this rule. Participants answered comprehension questions and rated the perceived difficulty. Results: For 11 of the 12 rules, we found that "violation" performed significantly worse than "rule" for the comprehension tasks. Regarding the subjective ratings, we found significant differences for 9 of the 12 rules, meaning that most violations were subjectively rated as more difficult to understand. Demographics played no role in the comprehension performance for "violation". Conclusions: Our results provide first empirical evidence for the importance of following design rules to improve the understandability of Web APIs, which is important for researchers, practitioners, and educators.Comment: Currently under review at Empirical Software Engineering (EMSE

Inter-Parameter Dependencies in Real-World Web APIs: The IDEA Dataset

Context: Web services often impose constraints that restrict the way in which two or more input parameters can be combined to form valid calls to the service, so-called inter-parameter dependencies. Current API design languages like the OpenAPI Specification (OAS) provide no support for their formal description, making it hardly possible to automatically discover and interact with services without human intervention. Researchers and practitioners are openly requesting support for modelling and validating inter-parameter dependencies in web APIs, but this is not possible unless we share a deep understanding of how these dependencies emerge in practice. Objective: We aim to provide evidence on how inter-parameter dependencies are used in real-world web APIs. This evidence will hopefully serve as a basis for future proposals for modelling and analysing inter-parameter dependencies and will open a new range of research possibilities in areas related to service-oriented computing. Method: The documentation of 2,557 operations from 40 real-world web APIs was reviewed and carefully analysed, and 633 inter-parameter dependencies were found and classified into seven different types. Results: A machine-readable dataset was generated. This dataset helps understand the dimension and recurrence of inter-parameter dependencies in web APIs, as well as their taxonomy.Ministerio de Ciencia e Innovación HORATIO (RTI2018-101204–B–C21)Junta de Andalucía APOLO (US-1264651)Junta de Andalucía EKIPMENTPLUS (P18–FR–2895)Ministerio de Educación y Formación Profesional FPU17/0407

EXPRESS: Resource-oriented and RESTful Semantic Web services

This thesis investigates an approach that simplifies the development of Semantic Web services (SWS) by removing the need for additional semantic descriptions.The most actively researched approaches to Semantic Web services introduce explicit semantic descriptions of services that are in addition to the existing semantic descriptions of the service domains. This increases their complexity and design overhead. The need for semantically describing the services in such approaches stems from their foundations in service-oriented computing, i.e. the extension of already existing service descriptions. This thesis demonstrates that adopting a resource-oriented approach based on REST will, in contrast to service-oriented approaches, eliminate the need for explicit semantic service descriptions and service vocabularies. This reduces the development efforts while retaining the significant functional capabilities.The approach proposed in this thesis, called EXPRESS (Expressing RESTful Semantic Services), utilises the similarities between REST and the Semantic Web, such as resource realisation, self-describing representations, and uniform interfaces. The semantics of a service is elicited from a resource’s semantic description in the domain ontology and the semantics of the uniform interface, hence eliminating the need for additional semantic descriptions. Moreover, stub-generation is a by-product of the mapping between entities in the domain ontology and resources.EXPRESS was developed to test the feasibility of eliminating explicit service descriptions and service vocabularies or ontologies, to explore the restrictions placed on domain ontologies as a result, to investigate the impact on the semantic quality of the description, and explore the benefits and costs to developers. To achieve this, an online demonstrator that allows users to generate stubs has been developed. In addition, a matchmaking experiment was conducted to show that the descriptions of the services are comparable to OWL-S in terms of their ability to be discovered, while improving the efficiency of discovery. Finally, an expert review was undertaken which provided evidence of EXPRESS’s simplicity and practicality when developing SWS from scratch

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

A gap analysis of Internet-of-Things platforms

We are experiencing an abundance of Internet-of-Things (IoT) middleware solutions that provide connectivity for sensors and actuators to the Internet. To gain a widespread adoption, these middleware solutions, referred to as platforms, have to meet the expectations of different players in the IoT ecosystem, including device providers, application developers, and end-users, among others. In this article, we evaluate a representative sample of these platforms, both proprietary and open-source, on the basis of their ability to meet the expectations of different IoT users. The evaluation is thus more focused on how ready and usable these platforms are for IoT ecosystem players, rather than on the peculiarities of the underlying technological layers. The evaluation is carried out as a gap analysis of the current IoT landscape with respect to (i) the support for heterogeneous sensing and actuating technologies, (ii) the data ownership and its implications for security and privacy, (iii) data processing and data sharing capabilities, (iv) the support offered to application developers, (v) the completeness of an IoT ecosystem, and (vi) the availability of dedicated IoT marketplaces. The gap analysis aims to highlight the deficiencies of today's solutions to improve their integration to tomorrow's ecosystems. In order to strengthen the finding of our analysis, we conducted a survey among the partners of the Finnish IoT program, counting over 350 experts, to evaluate the most critical issues for the development of future IoT platforms. Based on the results of our analysis and our survey, we conclude this article with a list of recommendations for extending these IoT platforms in order to fill in the gaps.Comment: 15 pages, 4 figures, 3 tables, Accepted for publication in Computer Communications, special issue on the Internet of Things: Research challenges and solution