RESTful Webservices Lucas Batistussi – 8440792 Thiago Gottardi – 8428398

Roteiro Introdução Exemplos de REST Apresentação Prática Aula Prática Web Service SOAP HTTP REST Exemplos de REST Apresentação Prática Aula Prática

Web Service Uma aplicação servidora que permite interação de máquinas sobre a rede. Forma interoperável de transmitir dados. A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#webservice

SOAP Padrão mais completo que REST para webservice; Tráfego mensagens sobre HTTP ou outro protocolo; Simple Object Access Protocol – Protocolo Simples de Acesso a Objetos; Representa recursos utilizando documento estruturado XML (wsdl).

Exemplo SOAP

SOAP Desvantagens do SOAP: Proposta REST: Envelopes geram muito tráfego; Pouco inteligível para humanos; Proposta REST: Utilizar outros métodos HTTP para diminuir: Trafego; Tamanho da URL.

HTTP Protocolo de Transmissão de Hipertexto 1.1 (RFC 2616) URI: http://servidor/caminho_do_recurso O cliente conecta-se ao servidor e solicita o recurso; Fonte: http://datatracker.ietf.org/doc/rfc2616/

HTTP Protocolo de Transmissão de Hipertexto 1.1 (RFC 2616) GET: Permite a um cliente (ex: browser) requisitar uma informação: Cliente GET /caminho/recurso/instancia HTTP/1.1 From: usuario@endereco User-Agent: Navegador Content-Type: text/html HTTP/1.1 200 OK Date: Wed, 4 Jun 2013 23:59:59 GMT Content-Type: text/html; charset=utf-8 Content-Length: 1354 Servidor Fonte: http://datatracker.ietf.org/doc/rfc2616/

HTTP Protocolo de Transmissão de Hipertexto 1.1 (RFC 2616) POST: Permite a um cliente (ex: browser) postar uma informação: Cliente POST /caminho/recurso/instancia HTTP/1.1 From: usuario@endereco User-Agent: Navegador Content-Type: application/x-www-form-urlencoded Content-Length: 30 nome=Thiago&numerousp=8428393 HTTP/1.1 200 OK Servidor Fonte: http://datatracker.ietf.org/doc/rfc2616/

HTTP Protocolo de Transmissão de Hipertexto 1.1 (RFC 2616) DELETE: Permite a um cliente remover instancia de recurso no servidor: Cliente DELETE /caminho/recurso/instancia HTTP/1.1 From: usuario@endereco User-Agent: Navegador HTTP/1.1 200 OK Servidor

HTTP Método DELETE Deletar um recurso Não é suportado pela maioria dos browsers en forms XMLHttpRequest (AJAX calls) OK Solução: utilizar o método POST e um parâmetro de formulário do tipo “hidden”, como “_method” com o valor correspondente ao método!

Solução <form action="/posts/xxxxx" method="POST"> <input type="hidden" name="_method" value="DELETE"> <input type="submit" value="delete"> </form>

HTTP Protocolo de Transmissão de Hipertexto 1.1 (RFC 2616) PUT: Permite a um cliente colocar instancia de recurso no servidor: Cliente PUT /caminho/recurso/ HTTP/1.1 From: usuario@endereco User-Agent: Navegador Content-Type: application/xml Content-Length: 89 <?xml version="1.0" encoding="ISO-8859-1"?> <recurso><instancia>Olá</instancia></recurso> HTTP/1.1 200 OK Servidor

HTTP Método PUT Inserir um recurso Não é suportado em alguns browsers em Forms XMLHttpRequest (AJAX calls) OK Solução: mesma que a do DELETE!

REST Métodos HTTP como PUT e DELETE são raramente usados por browsers e o internet explorer; Representational State Transfer (REST) Proposta REST: Fazer uso desses métodos; Estabelecer um padrão inteligível de um recurso: Introduzido na tese de Roy Fielding (Universidade da Califórnia) (2000) após fazer parte da equipe que definiu o HTTP 1.1; Conjunto de princípios para o design de Webservices. * Citar que os métodos HTTP estão associados com as operações CRUD dos sistemas de informação

REST Uso: GET Abstração de camadas “Padrão” Web 2.0; Recurso como substantivo (URI – Universal Resource Identifier) Ação como verbo (Métodos HTTP – POST, GET, PUT, DELETE, PATCH); Tipo de Conteúdo (Content-Type MIME). GET Cacheable GET não afeta conteúdo; Abstração de camadas Serviços podem ser divididos em N camadas; “Padrão” Web 2.0; Usado por websites como: Google, Facebook e Yahoo.

REST: Recursos Entidade do sistema Exposto pela URI Estrutura hierárquica URLs limpas e intuitivas, human-readable, easy to remember Simplifica o desenvolvimento Facilita a manutenção Deve haver cuidado para não expor estrutura de diretórios do sistema pelas URIs! Isso facilita a quebra de segurança e invasão do sistema! http://www.shopping.com/notebook/mbp http://www.shopping.com/?product=notebook&model=mbp 19

REST: Recursos Exemplo de URI conforme ministrada nesta aula: Endereço completo de um recurso http://servidor/aplicativo/recurso/ Após a barra na frente de recurso pode-se especificar vários parâmetros http://servidor/aplicativo/recurso/parametro/ http://servidor/aplicativo/recurso/parametro/parametro/ http://servidor/aplicativo/recurso/parametro/parametro/parametro Etc.

REST: Combinações Um servidor pode ter comportamento diferente para cada uma das combinações entre: Caminho; Nome do Recurso; Parâmetros; Método HTTP; Content-Type.

REST: Estado do Servidor No REST: GET é usado apenas para pegar informação sem afetar o conteúdo no servidor; POST insere dados a uma instância de um recurso; PUT insere uma instância de um recurso; DELETE remove uma instância de um recurso;

Onde está o “erro”? GET /adduser/name/Lucas HTTP/1.1 GET /users/name/Lucas HTTP/1.1

Resposta!!! A opção (1) está incoerente pois altera o estado do servidor adicionando um usuário ao sistema Na URI /users/name/Lucas o substantivo ou RECURSO é users Forma REST de adicionar usuário: PUT /users/name/Lucas HTTP/1.1

Princípios: statelessness Não guarda informação sobre o estado atual da navegação no servidor (sessão) Requisição contém todas as informações Natural do protocolo HTTP!

Statefull: exemplo GET /book1 HTTP/1.1 RESPONSE: {“content”:{…}} prevPage++; nextPage = prevPage; return nextPage; GET /book1 HTTP/1.1 RESPONSE: {“content”:{…}}

Stateless: exemplo getPage(1) GET /book1/page/1 HTTP/1.1 * A própria URL armazena o estado da navegação! RESPONSE: {“next”:2, “content”:{…}}

Stateless: vantagens Economia de recursos do servidor (principalmente memória) Redução consumo de banda (cache) Diminuição do tempo de resposta página (cache) * As respostas podem determinar se um item pode ser cacheado. Isso diminui o número de requisições ao servidor, aumentando a performance! * Redução do consumo de banda e diminuição do tempo de resposta: o cache permite recuperar cópias locais (cliente) de recursos, ou seja, os dados não precisam ser recuperados no servidor

Exemplo: recuperar tweets de um usuário REQUEST GET https://api.twitter.com/1/statuses/user_timeline.json?include_entities=true&include_rts=true&screen_name=twitterapi&count=2 RESPONSE: application/json; charset=utf-8 [{"created_at":"Wed May 22 20:48:37 +0000 2013","id":337309045331460097,"id_str":"337309045331460097","text":"API v1 blackout testing is just about complete. API…. }]

Alguns frameworks com suporte RESTFul Popular Ruby On Rails Exemplo site: twitter.com ASP.NET Exemplos sites: microsoft.com, peixeurbano.com.br vRaptor – brasileiro (USP)

SOAP x REST SOAP: Ocupa mais banda (troca mensagens) Mais complexo Machine-readable Maior flexibilidade Segurança Tecnologia consolidada no mercado * Flexívelidade: suporta diversos protocolos, estruturas hierárquicas

SOAP x REST REST: Mensagens menores (apenas requisição) Simples Machine+Human-readable Menos recursos que SOAP * Recursos limitados: somente protocolo HTTP, mensagens curtas (para evitar consumir banda), segurança difícil de garantir)

Referências http://www.ibm.com/developerworks/webservices/library /ws-restful/ http://www.w3.org/TR/soap12-part1/ http://datatracker.ietf.org/doc/rfc2616/ http://www.w3.org/TR/2004/NOTE-ws-gloss- 20040211/#webservice