Web das Coisas WoT Software: APIs para IoT Prof. João Bosco Teixeira Junior
WoT Um novo paradigma para desenvolvimento de aplicações inspirado na ideia do IOT; Utiliza protocolos e padrões amplamente aceitos na internet como HTTP e URI; O objetivo é fazer com que a internet também possa englobar os objetos do dia-a-dia (geladeira, ar-condicionado, tv, carro, etc.) Fonte: http://www.nce.ufrj.br/labnet/pesquisa/cidadesinteligentes/minicurso-wot-final.pdf
WoT - Protocolos HTTP Além de transportar os dados, também é usado para manipular os objetos através dos métodos HTTP tais como GET, POST, PUT e DELETE; Através destes métodos é possível expor as funcionalidades de um dado objeto na internet; URI (Uniform Resource Identifier) Fornecem endereços únicos e globais para identificação dos recursos; REST Estilo arquitetural para desenvolvimento de aplicações distribuídas ROA (Resource Oriented Architeture);
HTTP Hypertext Transfer Protocol Implementa o serviço web arquitetura TCP/IP; Baseado no modelo Cliente-Servidor; Utiliza os serviços de transporte orientado a conexão na porta 80/TCP; Envio e recebimento de mensagens;
HTTP: Teste DIGITE C: S: # telnet www.terra.com.br 80 Connected to www.terra.com.br. Escape character is '^]'. GET /index.html HTTP/1.1 host: www.terra.com.br User-Agent: Mozilla/4.0 HTTP/1.1 200 OK Server: nginx Date: Thu, 07 Aug 2014 15:25:31 GMT Content-Type: text/html... Connection: keep-alive Digite <enter>
HTTP: Sessão Uma sequência de transações de requisição resposta usando a mesma conexão TCP; O cliente inicia a comunicação estabelecendo uma conexão TCP para uma porta do servidor, por omissão a porta 80; O servidor escutando naquele IP e naquela porta, retorna com HTTP/1.1 200 OK, juntamente com o resultado da requisição ou erro informado;
HTTP: URI Em TI, um Identificador Uniforme de Recursos (URI) - Uniform Resource Identifier (em inglês) é uma cadeia de carateres compacta usada para identificar ou denominar um recurso na Internet (wikipedia). <scheme name> : <hierarchical part> [? <query> ] [ # <fragment> ] http://www.boscojr.com/protcomseg/form.php?qualquer=algo#cap1
HTTP: Métodos Também chamados de verbos Usados para indicar a ação desejada sob o recurso O Recurso é indicado pela URI Principais métodos utilizados HTTP 1.0 GET, POST e HEAD HTTP 1.1 OPTIONS, PUT, DELETE, TRACE and CONNECT
HTTP: Métodos GET: Usado para solicitar um recurso do servidor; HEAD: É idêntico ao GET mas só vem o cabeçalho da resposta a requisição; POST: O método post é usado para solicitar ao servidor o processamento de informações enviadas no corpo da requisição. É maneira padrão usada para processar formulários web; PUT: Solicita que o objeto enviado junto a requisição, seja armazenada sob a URI fornecida. Se o recurso não existe ele é criado, se existe ele é modificado. DELETE: Pode ser usado para remover um recurso específico. TRACE: Ecoa o pedido recebido de modo que o cliente pode ver as mudanças ou adições (se houver) foram feitas por servidores intermediários. OPTIONS: Retorna os métodos http que o servidor suporta para determinada URL. Isso pode ser usada para checar a funcionalidade do servidor. CONNECT: Converte o pedido de conexão em um túnel TCP/IP transparente, geralmente para facilitar a comunicação criptografada com SSL (HTTPS) através de um proxy HTTP não criptografado. PATCH: Aplica modificações parciais para um determinado recurso. Um servidor web mínimo deve ter pelo menos os métodos GET e HEAD
HTTP: GET x POST É possível usar o método GET para enviar dados de formulários do servidor, porém não é aconselhável, pois os dados serão passados na URL, e podem ser facilmente reproduzidos numa tentiva de fraude no sistema. O método correto para envio do formulário é o metodo POST. Entrada no html para o método GET: <FORM action=form.php method=get> Entrada no html para o método POST: <FORM action=form.php method=post> Exemplos: : www.boscojr.com/protcomseg/form.php
HTTP: Códigos de Retorno 200 OK 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 405 Method Not Allowed 500 Internal Server Error 503 Service Unavailable
Fonte: http://www.restapitutorial.com/httpstatuscodes.html
Comunicação S2S
API - Aplication Programing Interface é um conjunto de rotinas e padrões estabelecidos por um software para a utilização das suas funcionalidades por aplicativos que não pretendem envolver-se em detalhes da implementação do software, mas apenas usar seus serviços. How to design a good API and why it matters Joshua Block - Google
API Comunicação S2S As APIs permitem que software fale com software. Para fornecer um serviço o elemento de software deve possuir uma interface de programação de aplicativo ou API. O Sistema operacional tem uma API (SPI) Muitos Protocolos de Aplicação fazem uso de uma API.
Exemplo API TTS google TTS: Text to Speak (Texto para fala) curl 'http://translate.google.com/translate_tts? ie=utf-8&tl=pt&q=tecnologias %20Inovadoras&tl=en&client=t' -H 'Referer: http://translate.google.com/' -H 'User-Agent: stagefright/1.2 (Linux;Android 5.0)' > google_tts.mp3
Características de uma boa API Fácil de Aprender e usar, mesmo sem documentação; Fácil leitura e manutenção de código que a usa; Fácil de estender; Apropriada a para o público alvo;
Componentes de uma API Funções Parâmetros Retorno Status
O grandes players da internet possuem APIs Google Facebook Ebay Twiter Amazon Youtube
API para APIs - Temboo Biblioteca de Processos de Programação Virtualiza os uso das APIs dos principais players de internet. Gera códigos que podem ser colados direto na aplicação. Conceito: Coreografia (Service choreography) Uma forma de composição de serviço na qual um protocolo de interação entre diversos serviços é definido de uma perspectiva global.
API para APIs - Temboo API do Player 1 Meu Software... API do Player 2 API do Player n COREOGRAFIA API do Player 1 Meu Software TEMBOO... API do Player 2 API do Player n
Temboo Hora da Prática (caderno de práticas: Pratica 1) Atualizando uma planilha no Google Drive
Aplicações RESTful e Arquitetura Orientada Recursos (ROA)
Midleware para Desenv. de aplicações distribuídas RPC, RMI, CORBA SOAP e WSDL REST CoAP Paradigmas para WoT
REST REST Representative State Transfer; Transferência de Estado Representativo; Definido por Roy T. Fielding em sua tese de PhD; Estabelece um conjunto de princípios para aplicações web distribuídas. Diz-se RESTful as aplicações que seguem esses princípios
Princípios de REST A interface da aplicação deve ser uniforme; Stateless: Uma requisição não depende de outra anterior, Toda informação necessária ao processamento deve está na própria requisição; Cacheable: O resultado das requisições podem ser armazenadas em cache; Client-Server: A comunicação deve ser cliente-servidor; Layered System (Camadas): O cliente não deve enxergar além das camadas adjacentes Code-on-Denand: A aplicação pode opcionalmente gerar código para que o cliente execute. Ex: Javascript; Fonte: http://whatisrest.com/rest_constraints/layered_system_profile
Interface Uniforme ou API Uniforme Definição de uma interface entre clientes e servidores. Desacopla os diferentes elementos da arquitetura. Princípios para uma interface uniforme: Baseada em recursos: Recursos são identificados individualmente através de URIs. Os recursos são separados de suas representações, que são enviadas ao cliente. A representação do recurso pode ser HTML, JSON ou XML. Manipulação dos Recursos através de Representações: Quando um cliente tem uma representação de um recurso, incluindo quaisquer metadados anexado, tem informações suficientes para modificar ou excluir o recurso no servidor, desde que tenha permissão para fazê-lo. Mensagens auto-descritivas: Cada mensagem inclui informações suficientes para descrever como processar a mensagem. Por exemplo, qual parser para invocar pode ser especificado por um tipo de mídia Internet (anteriormente conhecido como um tipo de MIME). As respostas também indicam explicitamente o seu cache de capacidade. Hipermídia como o motor da Estado da Aplicação: Clientes podem passar o seu estado via corpo da mensagem, Cabeçalhos ou URI. Já o servidor pode passar o estado para cliente via corpo da mensagem, códigos de retorno e cabeçalho.
Aplicações RESTful (De uma outra forma) Todas as coisas deve ter pelo menos um identificador Vincule as coisas Utilize métodos padronizados Recursos com múltiplas representações Comunique sem estado Fonte: http://www.infoq.com/br/articles/rest-introduction
1) Dê a todas as coisas um Identificador Use URIs para identificar tudo o que precisar ser identificado, especifique todos os recursos de "alto nível" que seu aplicativo oferece, se eles representam itens individuais, conjuntos de itens, objetos virtuais e físicos, ou resultados de computação. Coisas individuais Conjuntos de Coisas
2) Vincule as coisas Use links para referenciar coisas que possam ser identificadas (recursos) sempre que for possível. A resposta a uma requisição pode conter links para outros recursos
3) Utilize os métodos padrão Os clientes para interagir com os seus recursos devem implementar o protocolo de aplicação padrão (HTTP) corretamente, isto é, utilizar os métodos padrão: GET, PUT, POST DELETE e OPTIONS; O cliente em sistema distribuído pode solicitar: Leitura (Consulta), Escrita (Nova entrada), Alteração, Exclusão; REST não te diz quais métodos usar, isso depende da aplicação. Se precisar algum método para tratar um recurso use os do HTTP
3) Utilize os métodos padrão
4) Recursos com múltiplas representações O cliente pode querer escolher a forma que deseja receber as informações. Ex.: XML Vcard (vcf)
5) Comunique sem Estado Uma requisição do cliente para o servidor não deve depender de requisições anteriores; REST exige que o estado seja transformado no estado do recurso. O estado deve ser transformado em algo que possa ser consultado; Ou o estado do recurso é enviado ao cliente e lá deve ser mantido.
REST
Hora da Prática (caderno de práticas: Pratica 2) Ajustando o Apache para Tratar as URIs
ROA Arquitetura Orientada a Recursos URIs deve possuir correspondência com o recurso: http://www.fac.br/aluno/pedro Endereçabilidade: Todo recurso deve possuir pelo menos um endereço Sem estado: Requisições deve ser auto contidas Representações (JSON, XML, CSV, RSS) Cliente -> Servidor: Criação ou modificação Servidor -> Cliente: Requisição Links e conectividade: As representações de um recurso podem fornecer links para outros recursos Interface Uniforme
ROA Interface Uniforme GET: Usado para recuperar um recurso A resposta deve incluir em seu corpo a representação do recurso DELETE: Usado para apagar um recurso A resposta deve ter o status HTTP correspondente POST e PUT: Criação de Recursos A resposta deve ter o status HTTP correspondente PUT: Atualização de Recursos A resposta deve ter o status HTTP correspondente OPTIONS: Informa quais métodos o recurso suporta
Desenvolvimento de serviços - RESTful Passos: 1 - Levantamento de requisito 2 - Identificação de recursos 3 - Definição de representação de recursos 4. Definição de URIs
Exemplo: Sistema de Climatização Sensor de Temperatura + Sistema de Refrigeração Interface IP
Exemplo: Sistema de Climatização 1 - Levantamento Requisitos Incluir um comodo Conhecer a temperatura do comodo Ajustar a temperatura do comodo 2 - Identificação dos Recursos Cômodos Sistema de Refrigeração Sensor de Temperatura
Exemplo: Sistema de Climatização 3 Definição da Representação dos Recursos JSON : { temp, valor } JSON : { Endereço IP } Inclusão de um cômodo (nome do comodo na URI ) 4 Definição da URI Cômodo: /comodo Exemplo /quarto, /cozinha, /banheiro, etc... Temperatura /comodo/temperatura Ex: /cozinha/temperatura Resultado da requisição Enviado na requisição de inclusão
Exemplo: Sistema de Climatização Temperatura Sistema De Refrigeração Protocolos Zigbee, blutooth, usb, serial, IR GATEWAY 1 2 3 4 5 6 INTERNET 1 GET /quarto/temperatura (host: www.x.com) 2 200 OK Data: { temp, 21 } 3 PUT /quarto/temperatura (host www.x.com) Data: { temp : 21 } 4 200 OK 5 POST /cozinha (host www.x.com) Data: 192.168.0.10 6 200 OK
Formatos para transferencia de recursos RFC 4627 (JSON) Representa estruturas de dados em texto XXX - String [ 1, 2, 3 ] - Lista { A : B } - Par: Chave-valor (key-value pair) XML (W3C) CSV
Hora da Prática (caderno de práticas: Pratica 3) Construindo uma Aplicação RESTful para IoT
Segurança da Web da Coisas HTTP Auth SSL OpenID OAuth
Conclusões Uma boa API pode determinar o sucesso do negócio A Web das coisas expande o domínio da internet para objetos do nosso dia a dia. HTTP é usado como protocolo base para a Web das Coisas REST e ROA são os padrões arquiteturais básicos para web das coisas Os objetos expostos na web devem possuir algum nível de segurança
FIM