web das coisas – wot software: apis para iot prof. joão ... · put: solicita que o objeto...
Post on 08-Nov-2018
216 Views
Preview:
TRANSCRIPT
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
# telnet www.terra.com.br 80Connected to www.terra.com.br.Escape character is '^]'.GET /index.html HTTP/1.1host: www.terra.com.brUser-Agent: Mozilla/4.0
HTTP/1.1 200 OKServer: nginxDate: Thu, 07 Aug 2014 15:25:31 GMTContent-Type: text/html...Connection: keep-alive
C:
S:
DIGITE
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
MeuSoftware
API do Player 1
.
.
.
MeuSoftware
.
.
.
TEMBOO
COREOGRAFIA
API do Player 2
API do Player n
API do Player 1
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
GATEWAY
SistemaDe
Refrigeração
ProtocolosZigbee, blutooth, usb, serial, IR INTERNET
1
2
3
1 – GET /quarto/temperatura (host: www.x.com)2 – 200 OKData: { “temp” , “21” }3 – PUT /quarto/temperatura (host www.x.com)Data: { “temp” : “21” }4 – 200 OK5 – POST /cozinha (host www.x.com)Data: “192.168.0.10”6 – 200 OK
4
56
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
top related