You are on page 1of 7

Busca...

Arquitetura REST com Java: JAX-RS


Postado dia 15/12/2009 por Sérgio Azevedo Junior em Arquitetura, Programação  12

A necessidade de trocar informações entre aplicações motivou diferentes abordagens para


“integração de dados”. Desde soluções simples e questionáveis como utilizar um banco de
dados compartilhado, ou realizar troca de arquivos até soluções mais elaboradas que
utilizam objetos distribuidos (COM e Corba). Em diversos momentos não temos somente a
integração de sistemas diferentes mas a distribuição de um único sistema em diversas
partes também pode ser integrada da mesma maneira.

A solução de integração denominada Webservices, que já é relativamente simples de


implementar, é a mais utilizada hoje em dia, que vemos em profundidade no curso FJ-31.

A Web é amplamente utilizada e reconhecida principalmente por sua arquitetura robusta,


tolerante a falhas e escalável. Quem sustenta a Web nesses fatores e lhe dá todo este poder
é o protocolo HTTP. Este protocolo inocente que utilizamos “meio que sem saber” em
nossos navegadores de internet está presente na Web inteira, e inclusive em nossos
Webservices. Não seria ótimo se eles tirassem proveito das caracteristicas do protocolo
HTTP, sem que isso nos desse muito trabalho?
A especi ção JSR-311 JAX-RS de Restful webservices (que faz parte agora do Java EE 6)
tornou isso simples e possível. Diferentemente do tradicional SOAP – em sua versão
amplamente utilizada – e WSDL, o JAX-RS foca um pouco mais em URIs e nos detalhes do
protocolo HTTP para se bene ciar de seus recursos.

Como utilizamos o JAX-RS para buscar dados de um Pedido?

@Path("/pedido/{id}")
public class PedidoResource {
 @GET
@Produces( { MediaType.APPLICATION_XML })
 public Pedido getPedidoById(@PathParam("id") Long id) {
   PedidoDAO pedidoDAO = new PedidoDAO();
   Pedido pedido = pedidoDAO.getPedidoById(id);
   return pedido;
 }
}

Através da classe PedidoResource, disponibilizaremos os dados de nossos pedidos no


formato XML. Vamos supor que con guramos que este serviço esteja disponível no
endereço: http://caelum.com.br/rest/pedido. Para conseguirmos informações sobre o
pedido 10, podemos acessar a url http://caelum.com.br/rest/pedido/10, através de nosso
browser de internet favorito. E assim receberiamos um resultado parecido com este:

<pedido>
  <dataPedido>2009-12-10T18:50:57.173-02:00</dataPedido>
  <descricao>Pedido 10</descricao>
  <id>10</id>
  <total>3000.25</total>
</pedido>

A api JAX-RS nos permite trabalhar com o que foi denominado Restful WebServices. E
segundo a arquitetura REST nós devemos expor as informações importantes de nossa
aplicação como recursos. Para isso precisamos criar uma classe que é de nida pela
especi cação como RootResource. Em nosso exemplo a classe PedidoResource é a nossa ,
e para ser acessivel aos clientes fornecemos a ela um url através da anotaçao
@Path(“/pedido/{id}”), e o próprio JAX-RS reconhece {id} como sendo um parametro que
é enviado através do url.

Um recurso pode responder a operações do protocolo HTTP, dentre as quais destacam-se:


POST, GET, PUT e DELETE. Nós escolhemos que nosso serviço responderá apenas a
solitações do tipo GET, a anotação @GET acima do método getPedidoById é quem de ne
isso. Essas anotações de caminho e de qual método HTTP podem acessar determinado
método estão presentes em frameworks como o Spring MVC e o VRaptor.
Depois dizemos que uma solitação GET para nosso recurso irá produzir um resposta do
tipo XML, através da anotação @Produces( { MediaType.APPLICATION_XML }).

É impotante destacar que esta anotação não é a responsável por serializar o objeto no
formato XML. O JAX-RS usa o JAX-B como serializador padrão, basta para isso colocar a
anotação @XmlRootElement na classe desejada, assim como nós zemos em nossa classe
pedido.

@XmlRootElement
public class Pedido {
 
 private Long id;
 private String descricao;
 private double total;
 private Calendar dataPedido;
 //Getters e Setters...
 
}

Agora que entendemos melhor o nosso serviço, ou seja, como acessar nosso recurso,
podemos olhar melhor para nosso cliente. Como nosso cliente do serviço web pode ser um
simples browser de internet, conseguimos usar o browser para consumir nosso serviço
web porque eles já estão bem acostumados a realizar operações HTTP do tipo GET.

Mas os browser’s não são nossos únicos clientes. Podemos criar diferentes tipos, e
inclusive ter aplicações desktop como clientes. Vejamos um exemplo de uma aplicação
cliente, que o usa a API do httpclient do grupo apache:

public class CaelumRestClient {


 
  public static void main(String[] args) throws Exception {
    HttpClient httpClient = new HttpClient();
 
    GetMethod httpMethod =
      new GetMethod("http://caelum/rest/pedido/20");
 
    httpMethod.addRequestHeader("Accept", "application/xml");
    httpClient.executeMethod(httpMethod);
    Scanner scan =
      new Scanner(httpMethod.getResponseBodyAsStream());
    PrintStream ps = System.out;
    while (scan.hasNext()) {
      ps.println(scan.nextLine());
    }
    httpMethod.releaseConnection();
  }
}

Este cliente é bem simples, ele faz apenas o mesmo trabalho que o browser já havia feito.
Mas nada nos impede de implementar coisas bem mais interessantes. Poderiamos fazer
com que este cliente desserializasse nosso objeto pedido. Para isso precisarimos apenas de
um parser XML para extrair os valores do xml e depois popular um objeto Pedido com estes
dados. A partir daí poderiamos utilizar este objeto em nossa aplicação.

A única limitação é que esta representação XML não nos diz nada sobre quais ações estão
disponiveis para o nosso objeto Pedido, nem mesmo quais as relações desse recurso com o
mundo afora. Uma alternativa seria utilizar o restfulie framework muito discutido hoje em
dia e idealizado por Guilherme Silveira e desenvolvido em conjunto com o pessoal da
Caelum, que usa o conceito de hypermedia para expor além dos dados as ações que um
determinado objeto pode realizar.

Em breve teremos um post do próprio Guilherme sobre a importância do conteúdo


hypermedia na arquitetura REST. 

Compartilhe isso:

 

Relacionado

Mudanças simples x Soluções SPDY, HTTP2 e por que você Então você quer ser um
simples deveria conhecê-los arquiteto Java?
18/11/2010 25/02/2014 21/07/2010
In “Agile” In “Front-end” In “Arquitetura”

Estude online na Alura

Programação, Mobile, Front-end, Design & UX, Infraestrutura e Business

Tags: http, integração, Java, javaee6, jax-rs, rest, restful, roa, soa, webservices, xml

Sérgio Azevedo Junior


12 COMENTÁRIOS

Uchoaaa
15/12/2009 at 21:40 #

Cara, legal o post. Tou doido para trabalhar com o VRaptor 3


(e enteder bem o restfulie =)

[]s

Márcio
16/12/2009 at 00:27 #

Olá.

Gostaria de saber qual a versão do httpclient esta sendo utilizado ? Pois na versão que baixei
(ultima) algumas classes e interfaces não existem ou foram modi cadas.

Obrigado.

Sergio Junior
16/12/2009 at 12:18 #

Olá Márcio.

Neste exemplo eu usei a versao 4.0 do httpclient, você consegue baixa-la neste encereço:
http://hc.apache.org/downloads.cgi

Abraços

Francisco Souza
22/12/2009 at 10:06 #

Parabéns pelo artigo, Sérgio! =)

luiz
23/07/2010 at 00:55 #

Parabéns pelo artigo. Saberia me dizer como ca a questão de segurança para o


controle de acesso ao serviços via Rest?

Jeremias
12/06/2011 at 09:19 #

Artigo muito bom! Parabéns!

thiano
11/12/2013 at 11:19 #

Minha duvida e como eu consigo nessa arquitetura incluir uma segurança para que só pessoas
autorizadas consigam acessar os metodos? Alguns amigos colocam usuario e senha como
parametro para cada chamada do metodo como uma alternativa mas pra mim isso e tampar o
sol com a penera.

Allan Tenorio
14/07/2015 at 10:30 #

Uai gente, ta óbvio que a segurança em Rest ca pra camada SSL do HTTP ou HTTPS… ou
alguma outra que for implementada, já que a arquitetura Rest é aberta e como bem disse o
artigo, trata-se de um padrão suportado pelo HTTP/HTTPS.

Raneves
18/12/2015 at 16:16 #

amigo @thiano você precisa de uma solução como a Spring Security OAuth
http://projects.spring.io/spring-security-oauth/docs/oauth2.html
DEIXE UMA RESPOSTA

Comentário

Nome (Obrigatório) E-mail (Obrigatório) Site

Noti que-me sobre novos comentários por e-mail.

Noti que-me sobre novas publicações por e-mail.

Enviar comentário

BLOG DA CAELUM: DESENVOLVIMENTO, WEB, MOBILE, UX E SCRUM © 2019.

You might also like