proprietary and confidential bruno pereira web services rest

Proprietary and Confidential

Bruno Pereira

Web Services REST


Agenda

Definição e um pouco de história Motivação Arquitetura Implementação Como refinar a implementação Conclusão


REST - Definição

REpresentational State Transfer Termo proposto por Roy Fielding Estilo de arquitetura WS com arquitetura da internet Exploração extensa do HTTP


Um pouco de história

Final da década de 90: Aplicações distribuídas com HTTP + XMLImplementações customizadas sempreProtocolos própriosDiferentes abordagens de segurança, controle transacional, etc.

Desafio: Como vender middleware assim?


Surgimento WS-*Sem padrões, difícil vender middleware

Fabricantes padronizam implementações

WSDL

SOAP

UDDI

WS-Security

WS-Policy

WS-Addressing

Complexidade


Surgimento REST

Tese Roy Fielding Conjunto de regras simples Grupos de estudo IETF Especificações após uso maduro


Analogia das evoluções

WS-*

REST

Modelo OSI

TCP/IP

Muitas specs antes das implementaçõesModelo waterfall/cascata

Regras simplesSpecs acompanham implementaçõesModelo incremental

Scrum anyone??


Motivação

Porque implementar serviços REST? Protocolos menos complexos Mais poder e flexibilidade Arquitetura amplamente disponível Menos overhead de protocolo

No Silver Bullet!


Arquitetura dos web services REST


Estilo de acesso aos serviços


Estilo declarativo x imperativo

GET /usuario/123456

O quêComo

Método HTTP

URI do recurso

<soap:Envelope> <soap:Body> <globo:consultarUsuario> <id>123456</id> </globo:consultarUsuario> </soap:Body></soap:Envelope>

fazerEstaOperacao


Implementação de serviços REST


Problema proposto

Leilão do Mercado Livre Vendedor anuncia produto Interessados realizam ofertas Vendedor aceita melhor oferta Vendedor e comprador se avaliam


Serviços oferecidos Anunciar item Buscar ítens do vendedor Cadastrar usuário Realizar oferta Retirar oferta Buscar ofertas do item Buscar melhor oferta Aceitar melhor oferta Avaliar usuário Buscar avaliações do usuário


Modelagem com recursos

Recursos identificados: Usuário Item (produto) Oferta Avaliação

Como manipular estes recursos?

Defina seu protocolo de comunicação REST


Protocolo de comunicação REST

Perguntas importantes:1. Quais são os recursos?2. Quais são as URIs?3. Quais são os formatos manipulados?4. Que métodos HTTP são aceitos em cada URI?5. Que status HTTP deve ser retornado em cada

situação?6. Que cabeçalhos HTTP são relevantes em cada

situação?


Protocolo de comunicação RESTGET, POST, PUT, DELETE

SELECT, INSERT, UPDATE, DELETE

!=

Quanto mais CRUD, mais fácil definir protocolo REST é bem mais do que CRUD REST envolve interações entre Recursos

Como modelar serviço de “Aceitar melhor oferta”? Trivial com WS-*, não-trivial com REST Paradigma diferente, modelagem diferente


Protocolo de comunicação REST

Não posso usar PUT e DELETE, que posso fazer??

1. Reclamar2. POST com x-http-method-override E se eu precisar enviar dados em uma requisição sem corpo??Mesma receita!


Protocolo de comunicação RESTURI Método

/item/{id} GETPUT

/item/{id}/ofertas GETPOST

/oferta/{id}GETPUT

DELETE/usuario POST

/usuario/{id} GETPUT

/usuario/{id}/avaliacoes GET

/usuario/{id}/itens GETPOST

/avaliacao/{id} GET/avaliacao/de/{id}/para/{id} POST

Com URI + método, você é capaz de deduzir qual é o serviço em questão?


Arquitetura da implementação

Servlet como FrontController Uma classe processor por prefixo de URI


Arquitetura da implementaçãoPapel do Controller: Inicializa Processors Valida URI + método HTTP Encaminha requisição para processors

Papel do Processor: Parsing de URIs para obter parâmetros Parsing do corpo das requisições Valida requisição Acessa Service Layer e gera resposta


Validação de URIs + método HTTP

Controller registra URIs/Processor Processors anotam métodos com URI + método

HTTP Controller invoca método por reflexãoE se uma URI inválida foi invocada? Status HTTP 400 – Bad Request

URI válida invocada com método HTTP inválido? Status HTTP 405 – Method Not Allowed


Parsing de URIs

Processor conhece URI de cada método

@Mapeamento(metodo = "GET", pattern = PATTERN_ITEM_EXISTENTE)

buscarItem(HttpServletRequest, HttpServletResponse){ String[] tokens = request.getPathInfo().split("/"); String id = tokens[2]; Item item = itemService.buscar(id);


Parsing do corpo da requisição Processor conhece formato esperado pelo

método Mapeamento Java/XML e XML/Java com XStreamE se o corpo da requisição veio inválido? Status HTTP 400 – Bad Request

Como indicar o erro?

<erro> <codigo>2319</codigo> <mensagem>

Atributo XPTO é obrigatório

</mensagem></erro>

<erros> <erro> <codigo>2319</codigo> <mensagem> Atributo XPTO é obrigatório </mensagem> </erro> ...</erros>

OU


Clientes Java

Requisições HTTP com commons-http-client Mapeamento Java/XML e XML/Java com XStream Status HTTP é o mais importante Alguns headers são importantes também


Exemplo 1: Criação de Oferta

Obter usuário ofertante Obter item desejado Obter dados da oferta Montar URI de ofertas do Item Gerar corpo da requisição Conferir resposta

Cliente:


Exemplo 1: Criação de Oferta

Validar URI + método HTTP Parsing da URI para obtenção do item Parsing do corpo da requisição Chamada ao Service Layer Geração da resposta

Servidor:

Status HTTP da resposta Header Location


Exemplo 2: Avaliação de usuário

Obter usuário avaliador e o avaliado Obter dados da avaliação Montar URI da avaliação Gerar corpo da requisição Conferir resposta

Cliente:


Exemplo 2: Avaliação de usuário

Validar URI + método HTTP Parsing da URI para obtenção dos usuários Parsing do corpo da requisição Chamada ao Service Layer Geração da resposta

Servidor:

Status HTTP da resposta Header Location RESTFul DSL


Principais Status HTTP

Status

Utilização

200 Solicitação realizada com sucesso

201 Recurso criado com sucesso

400 Requisição inválida404 Recurso inexistente405 Método HTTP não

permitido para a URI500 Erro interno no servidor


Como refinar a implementação


Flexibilidade nas respostas

Me diga o que queres

Seja feita vossa vontade

Accept: text/xml,application/

json<usuario> <login>blpsilva</login> </usuario> <usuario> <login>teste999</login> </usuario>

"usuarios":[ { "login":"blpsilva", }, { "login":"teste999", }]

OU

Uma interface,múltiplos formatos


Flexibilidade nas requisições

Me diga o que estás mandando

Content-Type: text/xml;

OU

Uma interface,múltiplos formatos!

charset=UTF-8

Content-Type: application/json;charset=ISO-8859-1

Eu converto e processo


Flexibilidade nas requisiçõesImplementar esta flexibilidade é muito trabalhoso… JSR-311/Jersey

Mas meus serviços são em Ruby/Php/Perl/Python… Lots of fun for you!

Minha aplicação roda no Vignette, não tenho Java 5…

… é uma pena quando isso acontece!


JSR-311/Jersey

URIs mapeadas em classes/métodos Parâmetros extraídos das URIs Conversões xml/json/etc -> Java Conversões Java -> xml/json/etc Manipulação de status/headers HTTP


Dúvidas comuns

Como tratar a paginação de resultados? Como implementar links entre recursos? Como lidar com acessos concorrentes? Como autenticar/autorizar operações?

Atom + AtomPub + Apache Abdera Blueprint de implementação REST Excelente para conteúdo web Google, Microsoft E Globo.com já usam


ConclusãoWeb services antigamente: Troca de performance por interoperabilidade

Web services atualmente: Alta performance E interoperabilidade Flexibilidade absoluta

Web services no futuro: Forma padrão de comunicação entre aplicações? REST everywhere


Dúvidas??


Quer conhecer mais?

Nas bancas: Java Magazine 56 – Abril/2008


Contato

[email protected]://blpsilva.wordpress.com

proprietary and confidential bruno pereira web services rest

Documents