A Web of Things concentra-se principalmente sobre o estabelecimento de conectividade à Web de dispositivos os quais podem estar em ambientes de rede restrita ou possuir recursos computacionais restritos, exatamente o caso de RSSF para o qual o Midgard foi projetado para atuar. Assim, é necessário pensar-se em modelos de interação escaláveis no topo da conectividade de rede. Nos conceitos da WoT, smart things e os seus serviços estão totalmente
integrados na Web através da reutilização e adaptação de tecnologias e padrões comumente utilizados para conteúdos da Web tradicional. Mais precisamente, pequenos servidores Web são incorporados em smart things e o estilo arquitetural REST - (Representational State Transfer) [Richardson e Ruby 2007; Fielding 2000] é uma arquitetura adequada e aplicada a esse tipo de cenário (Guinard et al 2010C;. Luckenbach et al 2005;. Duquennoy et al. 2009; Hui e Culler 2008) [Guinard et al ,2010 - 5].
A essência do REST concentra-se na criação de serviços fracamente acoplados na Web, de modo que possam ser facilmente reutilizados. REST é o estilo arquitetônico da Web, implementado por URIs, HTTP e tipos padronizados de mídia, como HTML, JavaScript Object Notation (JSON) e Extensible Markup Language (XML), o qual utiliza URIs para identificar recursos na web. REST abstrai serviços em uma interface uniforme (através de métodos HTTP's) a partir de sua semântica de aplicações específicas e fornece mecanismos para que os clientes selecionem as melhores representações para interações. Isso o torna um candidato ideal para construção de arquiteturas e APIs "universais" para smart things [Guinard et al, 2010 - 5].
O paradigma REST abrange um pequeno grupo de conceitos e princípios, apresentados a seguir, não havendo qualquer conexão direta entre este paradigma e outro protocolo específico. Abordaremos neste trabalho o conceito de RESTful apresentado em [Richardson e Ruby, 2007]. Esses autores definem o termo Serviços RESTful para designar serviços Web que seguem os critérios defendidos pelo paradigma REST, os quais serão tratados para implementação do Midgrad.
Baseados na filosofia REST e na Web, surgiram os serviços Web baseados em REST. Nessa vertende tecnológica, os serviços REST compõem a maioria dos serviços disponibilizados na Web 2.0 notoriamente focada na geração colaborativa de conteúdo. Em serviços Web baseados em REST, a interface uniforme dos métodos é dada pelos métodos definidos no protocolo HTTP [RFC 2616], sendo os principais o GET, POST, DELETE e PUT. Com esses quatro métodos, é possível realizar qualquer operação sobre os
recursos. Assim, serviços Web baseados em REST são orientados a recursos [Berenguel et al, 2008].
O protocolo HTTP foi definido pelo W3C como o protocolo padrão para a transmissão de mensagens na Web. Tal compatibilidade faz com que todo sistema projetado de acordo com o paradigma RESTful tenha uma potencial audiência por todos os dispositivos conectados à Web. Outra conseqüência igualmente benéfica é a utilização da própria Web como infra-estrutura de distribuição e acesso, o que torna o sistema inteiramente portável, sem qualquer dependência adicional em termos que hardware ou software. Como todo serviço Web, um serviço RESTful recebe uma requisição discriminando o processamento a ser executado e retorna uma resposta, detalhando o resultado obtido.
Os serviços RESTful devem seguir os conceitos de (i) recurso, (ii) representação, (iii) identificador uniforme, (iv) interface unificada e (v) escopo de execução. Um recurso consiste em uma abstração ou em um conceito relevante existente no domínio tratado. Qualquer objeto do domínio pode ser um recurso, seja um objeto real ou fictício, concreto ou abstrato. Recursos podem ser web sites, weblog como também objetos físicos, como sensores.
Os serviços podem manipular apenas as representações dos recursos, haja vista que os recursos se constituiem de abstrações, como explicitado anteriormente. Conceitualmente, uma representação consiste em qualquer informação útil sobre o estado do recurso [Richardson e Ruby, 2007]. Tecnicamente, uma representação caracteriza-se por uma serialização das informações disponibilizadas pelo recurso em uma sintaxe escolhida. Os formatos de sintaxe comumente utilizados são, por exemplo, XML (Extensible Markup Language), XHTML (Extensible Hypertext Markup Language), JSON (JavaScript Object Notation), RDF (Resource Description Framework), entre outros. Entrentanto, pode existir múltiplas representações de um único recurso, ou seja, uma representação pode está codificada em diferentes formatos de dados ou diferentes linguagens, cabendo ao servidor escolher o formato ou linguagem apropriado para retornar a informação.
Cada recurso possui um identificador uniforme, estando necessariamente associado a pelo menos um URI (Uniform Resource Identifier). Esse URI atua simultaneamente como nome e localizador do recurso, como por exemplo http://sensor ou http://sensor/light. Caso um determinado objeto não possua um URI associado, ele não poderá ser considerado um recurso, porém, um único recurso pode ser referenciado por um número ilimitado de URIs.
O padrão RESTfull oferece uma interface unificada para todos os
serviços. Na ocasião em que um determinado consumidor conheça os recursos oferecidos por um serviço em particular, ele automaticamente conhece os processos de recuperação, criação, modificação e remoção destes recursos. Segundo o paradigma RESTful, a ação a ser executada é definida diretamente pelo protocolo HTTP. O protocolo oferece cinco métodos principais: GET, HEAD, POST, PUT e DELETE. Todos os métodos são aplicados nos recursos, ou seja, nos objetos gerenciados pelo serviço. Mais especificamente, um método HTTP é executado para um determinado URI. No tocante a definição
de escopo de execução do método, o paradigma RESTful defende a
utilização do URI presente na requisição HTTP para este fim. Nesta abordagem, o URI contém não apenas o caminho do serviço em questão, mas também qualquer parâmetro necessário para identificação única do recurso afetado.
Para o cenário de RSSF, os conceitos principais que tornam RESTful adquados para utilização nesse ambiente consiste na possibilidade de um dispositivo poder recuperar e registrar dados através dos métodos GET e POST do protocolo HTTP, respectivamente. Essas características são vantajosas, pois a adoção desse padrão pelo Midgard permite que aplicações web possam consumir os dados presentes na RSSFs de forma transparente, possibilitando o desenvolvimento de vários serviços web que utilizem esses dados. O Midgard fornece API e interfaces que permitem a um componente expor suas propriedades como recursos RESTful, facilitando a integração de todos os componentes com a Web e consequentemente alinhando-se com o paradigma Web of Things [Guinard et al, 2010].
Conforme explicitado anteriormente, o Migard suporta o padrão REST, tornando as RSSFs serviços Web orientados a recursos (serviços RESTful) e acessíveis por meio do protocolo http [RFC 2616], ou seja, fazendo uso de suas 4 operações básicas (GET, POST, PUT e DELETE). Por exemplo, no contexto do Midgard, o método GET é utilizado para obter dados dos nós sensores, como a temperatura ambiente. Para obter esse dado, deve-se realizar um GET em uma URL como “/sensor/temperature”. Por sua vez, o método POST é usado para adicionar novos dados a aplicação que executa no nó sensor. Podemos citar como exemplo de uso do método POST: quando o cliente deseja ativar os limites de medição da temperatura no nó sensor com o objetivo de informar ao nó sensor em qual intervalo de temperatura ele está interessado. Dessa forma, o cliente deve realizar um POST com os parâmetros max e min na URL “/sensor/temperature/thresholds”. Caso deseje-se alterar os valores limite, uma vez que eles já existem, o método que deve ser utilizado é o PUT. Para atualizar os limites, o cliente deve usar o método PUT com os novos valores para os parâmetros max e min na mesma URL. Por fim, o método DELETE deve ser utilizado na remoção de dados da aplicação. Caso um cliente deseje informar que o nó sensor não deve mais restringir as medições de temperatura em determinados limites, o cliente deve realizar um DELETE na
URL “/sensor/temperature/thresolds”. Com relação a representação do
recurso, no Midgard optou-se por adotar o JSON, que é um formato leve, portanto adequado para o ambiente restrito das RSSFs.