Marcio Garcia

Recentemente eu precisei de trabalhar em um projeto onde toda a comunicação entre o frontend e o backend era feita através de requisições HTTP. A princípio consideramos utilizar um Servlet com alguns helpers que mapeava os parâmetros de URL para um Map e internamente esse Map era “injetado” em todas as classes de recurso.

Era uma solucão a ser considerada, mas como essa era a primeira idéia que o time teve, resolvemos descartá-la.

Por uma requisição do cliente, tinhamos que utilizar Maven e Spring e isto era ponto fechado. As demais bibliotecas eram por nossa conta (e risco).
Surgiu então a segunda idéia de utilizar RESTful simplesmente para facilitar o trabalho entre o mapeamento dos parâmetros vindos da URL com o código.

Pesquisamos a primeira Lib, Jersey já quer esta é a implementação padrão do JSR-311 e também pesquisamos a API do Restlet.
Resolvemos nos contrapor a ideologia de rejeitar a primeira opção a fim de conseguir novos recursos.
Ambos frameworks possuem aspectos únicos e muito bem documentados. Cada uma com suas particularidades, por exemplo no Restlet é necessário criar uma classe com as rotas (uma classe que extende a classe Application).

Mas os principais motivos que nos levou a decidir a utilizar o Jersey foram:

1. Ser a implementação modelo da especificação
2. Menos burocracia na implementação dos resources
3. Integração quase que natural com o Spring para a injeção de classes nos resources.

Este “walk through” tem o objetivo de exemplificar como criar uma aplicação simples utilizando as ferramentas: Spring, Maven e Jersey de forma prática.

Setup

1. Incluir o repositório do jersey-spring no pom.xml



2. Incluir as dependencias das libs: jersey spring


3. Configurar web.xml

It’s time do code!

1. Configuração do Spring (applicationContext.xml)
Crie o arquivo applicationContext.xml no diretório META-INF de sua aplicação. Este código informa ao engine do Spring para que o pacote com.mng.jerseydemo esteja disponível para a injeção de dependencias. Segue o modelo do arquivo:

2. Criação do primeiro resource.

Neste trecho de código existem algumas anotações, entre elas:


1. @Path
Este é o padrão da URL que será tratado pela classe. Pode ser informado variáveis utilizando o modelo: {nomeDaVariavel}. Por exemplo: @Path(”/user/{username}/{password}”).

2. @Autowired
Injeta um objeto do tipo informado na váriavel.

3. @GET
Responde as requisições do tipo GET, existem ainda: @POST, @PUT e @DELETE que podem ser utilizadas da mesma maneira que o @GET

4. @Produces
Informa o tipo de retorno do método. Esta anotação pode ser informada tanto no método quanto na classe, junto com o @Path. Informando na classe o tipo de retorno será propagado para todos os métodos que não tenham um @Produces específico.

5. @PathParam
Traduz as variáveis mapeadas na URL para um objeto. Este será mapeado para uma variável informada na assinatura do método.

Acessando

Para acessar o recurso recém criado voce pode utilizar o próprio browser (Chrome ou Firefox), com eles fica fácil de simular o GET. No entanto, se você está no mundo X (Linux, Unix ou mesmo Mac) faça bom uso do cUrl. De forma rápida e prática este comando é simples de ser utilizado.
Através do parametro “-X” especificando o método que deverá ser enviado é possível testar a maior parte dos serviços:

E com o parâmetro -F você pode especificar os parâmetros (@QueryParam) do método post.

Desde um pouco antes de minha passagem pela Austrália tenho me dedicado a estudar sobre código e formas de codificar. Melhores e piores técnicas. Na época que passei na Austrália essa dedicação foi amplificada, pois como não estava trabalhando e nem a procura de um emprego passei muito tempo apenas lendo a respeito e aplicando algumas técnicas em códigos pessoais.

Nomes Significativos.

Se você ainda não teve uma experiência como esta, você é uma pessoa de sorte, mas em alguns casos você é obrigado a trabalhar com a restrição de oito caracteres para nomes. Essa “lei” se aplica para banco de dados antigos que não evoluíram.

Mas isso não quer dizer que o seu código (Java, C#, Ruby….) deva seguir este modelo. Os nomes das variáveis, métodos devem ser ao menos significativos.

Veja o seguinte trecho de código:
Este é apensa um exemplo, mas tais variáveis não dizem nada, absolutamente nada sobre a intenção das mesmas. Além do mais, você como um programador deve codificar mentalmente o que significa as variáveis cor e pal dentro do contexto. Agora leia o código a baixo:



Não é mais simples? Foi necessário alguma decodificação mental a respeito da intenção das variáveis?

Nomes de Métodos e Construtores.

Outra regra muito fácil aprendida na faculdade é de que o nomes para métodos devem ser verbos, expressando uma ação. Como por exemplo: get / set / is / do…..

Mas e com relação a construtores? Estes não são nada próximos de amigáveis ou mesmo significativos.
Uma boa saída é criar métodos estáticos dentro da própria classe informando o motivo para aquele construtor estático, por exemplo:



Este é um exemplo muito pequeno e sem nenhum contexto. Ainda neste código o nome do método construtor createComplete poderia ser renomeado apenas para create, caso existisse uma convenção em toda a aplicação de que o método chamado create precise de todos os parâmetros do objeto para ser criados.
Uma outra alternativa seria criar um construtor static ao invés de informar o parâmetro faltante - state - que não é algo muito legível, utilizar um contexto para esta criação, como por exemplo: createForSelect, sendo utilizado para a criação de um objeto City para ser utilizado em um campo html select.