Artigo Java Magazine 56 - Web services REST uma abordagem prática

Web services REST

Uma abordagem prática

Implementação de web services flexíveis e poderosos explorando os recursos do HTTP

Na Edição 54 fizemos uma análise pragmática dos web services REST e WS-*, visando comparar de forma imparcial as características mais importantes das duas linhas de desenvolvimento. Na edição passada, passamos para uma abordagem prática, partindo de um exemplo de serviços do Mercado Livre dentro do contexto de leilões de produtos.

A implementação destes serviços no artigo anterior foi feita com uso da linha de web services WS-*, através da pilha do Apache Axis 2. Complementando esta série sobre desenvolvimento de web services, neste artigo iremos partir do mesmo problema de leilões do Mercado Livre, mas realizar a implementação de uma maneira RESTful.

Os web services REST surgiram de uma proposição na tese de doutorado de Roy Fieding, que entre outras coisas é o principal autor da especificação HTTP e um dos fundadores da Apache Software Foundation.

A sigla REST significa REpresentational State Transfer, sendo um estilo de arquitetura que tem como princípio central a manipulação de Recursos. A principal característica dos serviços que usam verdadeiramente este estilo é a exploração rica do protocolo HTTP.

Provavelmente a maior razão por trás do sucesso atual dos serviços REST comparando com a pilha WS-* é a simplicidade do seu conjunto de regras básicas. O consórcio de empresas que participou da definição dos padrões WS-* elaborou especificações para cenários bastante diversificados. Tentou-se elaborar padrões para todas as situações que pudessem surgir para desenvolvimento de serviços. Como conseqüência disso, chegamos num ponto onde apenas indivíduos que participam ativamente deste consórcio conseguem ter domínio amplo sobre os padrões WS-*. Desenvolvedores que utilizam esta pilha de padrões para resolver problemas reais conhecem apenas um sub-conjunto bem menor das especificações geradas pelo consórcio.

Na direção contrária deste movimento, os desenvolvedores de serviços REST se fundamentaram em um conjunto de idéias simples e fortemente associado ao que é comumente usado na internet. As principais tecnologias adotadas envolvem HTTP e XML. Os arquitetos desta linha de implementação foram progressivamente adotando soluções inteligentes para resolver problemas comuns. Com os blueprints já disponíveis e o amadurecimento das discussões, estamos avançando em um caminho de soluções poderosas que não perdem a simplicidade essencial do REST.

O objetivo deste artigo é explorar novamente o problema de leilões do Mercado Livre, e detalhar todos os aspectos envolvidos em uma implementação de serviços REST. Comparando duas abordagens diferentes para o mesmo problema, pode-se ter uma boa idéia dos conceitos principais de cada abordagem. Estudar a arquitetura utilizada para este artigo e confrontá-la com a do artigo passado permitirá que o leitor perceba nuances importantes das duas formas de implementação de web services, e então ter na mente os principais questionamentos que se deve fazer ao escolher uma das duas para resolver um determinado problema.

Para este artigo, decidimos não introduzir tecnologias e frameworks que pudessem ocultar detalhes importantes dos serviços REST. A idéia é adotar uma implementação que permita apresentar de forma nítida os conceitos envolvidos. Em artigos posteriores, será feito o detalhamento de frameworks e componentes que podem refinar a arquitetura e agregar produtividade ao desenvolvimento.

Apresentação do problema

O problema que buscaremos resolver é o mesmo da edição passada, e envolve serviços relacionados a um leilão do Mercado Livre. Um usuário cadastrado no site coloca para venda um produto (novo ou usado), definindo um valor para o lance inicial e então aguarda pelas ofertas de compra por parte de outros usuários interessados no produto.

Após receber algumas ofertas pelo produto, em determinado momento o vendedor decide aceitar a melhor oferta recebida, e então vende o produto para o comprador que fez esta oferta, encerrando o leilão. Em seguida ocorrem os trâmites de pagamento e entrega do produto (que não trataremos aqui) e no final, vendedor e comprador avaliam um ao outro, o que é essencial para os usuários sentirem maior segurança ao realizar negociações futuras.

Na modelagem desta aplicação, quatro classes serão utilizadas: Usuário, Item, Oferta e Avaliação. Os serviços a serem oferecidos podem ser vistos no quadro “Serviços oferecidos no processo de leilão”. Para permitir uma comparação adequada, os serviços em questão são os mesmos do artigo anterior.

Serviços oferecidos no processo de leilão

A primeira etapa na elaboração de uma arquitetura orientada a serviços é a identificação dos serviços que serão disponibilizados para interação com a aplicação e/ou empresa em questão.

No nosso exemplo do leilão, os serviços envolvidos manipulam Usuários, Itens, Ofertas e Avaliações, conforme identificado na modelagem. A Tabela 1 descreve as operações que poderão ser realizadas por quem estiver se integrando ao processo de leilão.

Tabela 1. Serviços oferecidos para interação com o processo de leilão

Visão geral da implementação

Já vimos na edição passada uma abordagem com o estilo de serviços WS-*. Na aplicação de exemplo desenvolvida foram codificadas todas as camadas. Desde a persistência com DAOs, passando por uma camada de ServiceLayer (padrão de projeto proposto por Martin Fowler, e descrito no mesmo artigo) e chegando aos web services implementados com uso do Apache Axis 2.

Para a versão RESTful dos serviços do Mercado Livre, reaproveitaremos toda a estrutura definida no artigo anterior, com exceção dos web services, que deixam de utilizar a pilha WS-* para definir um protocolo de comunicação com extensa exploração do HTTP.

Com este re-uso da arquitetura e componentes da implementação anterior, omitimos os detalhes de configuração de ferramentas (Derby, Tomcat e Eclipse), pois isto pode ser conferido adequadamente no outro artigo." [...] continue lendo...