Um Modelo de Comunicação para Automação na Execução de Consultas de Dados sobre APIs Web

Transcript

1. Um Modelo de Comunicação para Automação na Execução de Consultas de Dados sobre APIs Web. Mateus Maso
2. Roteiro • Introdução • Desenvolvimento • Validação • Conclusão
3. Introdução
4. APIs Web
5. 2006-2007 => +192% 2007-2009 => +260% 2009-2010 => +150% 2010-2011 => +141% 2011-2012 => +146% 2012-2013 => +205% ...
6. => Modelo de consultas sobre APIs Web 1. Identificar serviço. 2. Entender especificação da API. 3. Escrever código de busca baseado na especificação. fetch("/users/1/photo") GET /users/:id/photo
7. Problema do modelo • Acoplamento entre código de busca e especificação. ◦ Dificulta mudanças na especificação ao longo do tempo. ◦ Promove versionamento muitas vezes desnecessário da API. => fetch("/users/1/photo") GET /users/:id/photo
8. => • Arquiteturas demand-driven. ◦ Código de busca através de linguagens de consulta. ◦ Diminuir necessidade de alteração na especificação. ◦ Requer implementação em ambos os lados. Melhoria no modelo QUERY users[1].photo POST /query
9. => • Independente de especificação de API. ◦ Código de busca através de linguagens de consulta. ◦ Mudanças na especificação não influenciam. ◦ Requer implementação apenas no cliente. Modelo proposto QUERY users[1].photo GET ou POST /...
10. • Automação na execução de consultas de dados. ◦ Formatos para descrição de metadados de APIs ▪ JSON Hyper-Schema ◦ Linguagens para consulta de dados ▪ GraphQL Como? Metadados de APIs + Linguagem de Consulta
11. JSON Hyper-Schema • 2012 Kris Zyp. • Formato de descrição de API. • Completo para descrever APIs REST para máquinas. => GET /users/:id "links": [{ "href": "/users/{id}", "schema": { ... }, "targetSchema": { ... } }]
12. GraphQL • 2015 Facebook. • Linguagem de consulta e interpretador. • Consulta de dados sem interagir com especificação. => { user(id: 1) { name } } "Query": { "user": (id) => { fetch("/users/${id}") } }
13. Desenvolvimento
14. Planejamento de Projeto 1. Descrever o modelo proposto. ◦ Criação de uma ferramenta. 2. Desenvolver especificação da ferramenta. ◦ Ser replicável em diversas plataformas. 3. Implementar ferramenta para validação. ◦ Analisar resultados. 4. Disponibilizar ferramenta para comunidade de dev. ◦ Open Source.
18. Implementação da Ferramenta • Dois processos ◦ Criaçã o do intermediador. ◦ Consulta de dados no intermediador. • Onze funçõ es no total ◦ Quatro responsá veis por criar o intermediador. ◦ Três para analisar consultas atravé s do formato AST. ◦ Quatro para transformar consultas em requisiçõ es na API.
21. Validação
22. Ambiente de testes • Dois clientes. ◦ Mesma lógica de aplicação. ◦ Diferente código de busca. (sem/com ferramenta) • Três perguntas. (Q1, Q2, Q3) ◦ Fluxo de dados pré-determinado. ◦ Resposta exata. • Seis entidades. (SWAPI) ◦ API REST.
23. Mudanças na especificação da SWAPI • Afetam o fluxo de dados. ◦ C1: Mudança de acesso. ◦ C2: Mudança no nível da estrutura de resposta. ◦ C3: Introdução de novos endereços. ◦ C4: Substituição de endereço deprecated. • Não acumulativas.
24. Variáveis de análise • Porcentagem de acerto. (%) • Número de requisições. (inteiro) • Tamanho de resposta. (kb) • Tempo de busca de metadados. (ms) • Tempo de processamento. (ms)
25. Resultados obtidos • Aumento de 36.61% no índice de acerto. ◦ 91,5% de acerto (C4 não permitiu 100%). • Consultas com melhor desempenho. (C3) ◦ Redução de 53% no nú mero de requisições. ◦ Evitou transferência de 4.23 kb de dados. • Atraso em 1.7 segundos na execuçã o. ◦ Tempo de busca de metadados == 70% atraso inicial.
29. Conclusão
30. Aprendizado • Dificuldades de serviços em realizar mudanças. • Explorar novos modelos de comunicaçã o. • Vantagens do modelo proposto ◦ Diminuir preocupaçã o de clientes em estar continuamente atualizando seu có digo de busca a cada mudança na API ◦ Direcionar desenvolvedores de clientes à implementaçã o de có digos de busca independente de especificaçã o de API. • Custos de integração no cliente e overhead. ◦ Limitado acesso em APIs que possuem metadados.
31. Contribuições • Benefí cios da automaçã o na execuçã o de consultas. ◦ Linguagens de consulta. ◦ Descriçã o dos metadados de APIs. • Possíveis benefícios da composiçã o de serviços. ◦ Não testado. • Ferramenta e adaptador JavaScript. ◦ https://github.com/mateusmaso/graphql-jay ◦ https://github.com/mateusmaso/graphql-jay-hyperschema
32. • Realizar testes de composiçã o de serviços. • Criar novos adaptadores para formatos de APIs. ◦ OpenAPI, RAML, API Blueprint. • Implementar ferramenta em outras plataformas. ◦ Mobile, Desktop. • Melhorar algoritmo de aná lise de consultas. Trabalhos futuros
33. Obrigado