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