[RESOLVIDO]WebService RestFul, url com muitos parametros, o que fazer?

Front-end
#1

Boa tarde galera blz?

Ao andar da carruagem encontrei um problema, vamos dizer criei uma “bola de neve” , e isso ta crescendo cada vez mais.

Existem uma aplicação php onde faz requisições ao meu webservice para obter as informações do banco. Ate ai td ok.

O problema que eu encontrei foi na parte de filtros, a url onde o php faz requisição e passa os filtros para consulta ta ficando muito grande, e penso eu que a maneira na qual estou fazendo não é a mais adequada no momento.

[code]@Path("/materiaLegislativa")
public class MateriaLegislativaResource {

@GET
@Path("/{numeroPagina}/{situacao}/{numeroMateria}/{localizacaoAtual}/"
  + "{protocolo}/{tipoMateria}/{ano}/{tipoAutor}/{autor}/{legislatura}/{relator}")
@Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
public Object getFiltro(@PathParam("numeroPagina") Integer numeroPagina, 
		    @PathParam("situacao") Integer situacao,		    
		    @PathParam("numeroMateria") String numeroMateria,
                        @PathParam("localizacaoAtual") Integer localizacaoAtual, 
		    @PathParam("protocolo") Integer protocolo, 
                        @PathParam("tipoMateria") Integer tipoMateria, 
		    @PathParam("ano")Integer ano,
                        @PathParam("tipoAutor")Integer tipoAutor, 
		    @PathParam("autor")Integer autor,
		    @PathParam("legislatura")Integer legislatura,
		    @PathParam("relator")Integer relator) {
    
    
    return MateriaLegislativaDAO.getInstance().getMateriaLegislativa(numeroPagina, situacao, numeroMateria,
        localizacaoAtual, protocolo, tipoMateria, ano, tipoAutor, autor, legislatura, relator);

[/code]

Sei que o certo de um metodo é nao ter mais que 5 parametros por questao de padronização.

Alguem sabe como posso resolver isso? Um amigo de trabalho deu a ideia de me passar um json com os parametros e assim eu ver que tipo de parametros são.

Gostaria de opinião de vcs, se existe uma melhor forma de resolver isso.

Obrigado =]

#2

A primeira coisa a se fazer é transferir o que for opcional para query params (aqueles que vêm depois da ‘?’ , sabe?). Por exemplo, suponha que, no caso do parâmetro ano, o que acontece se ele não for passado? O ano é inferido como o atual, por exemplo?

Feito isso, o próximo passo é cortar parâmetros. Se você tem muitos assim, isso é sintoma de uma modelagem ruim. Na definição da URL, devem entrar apenas os elementos de mais alto nível e sub-elementos. Por exemplo, suponha o seguinte: uma aplicação tem uma definição de perfis. Cada perfil tem vários usuários, cada usuário tem várias formas de contato. O que fazer? Simples: cada um desses deve ser um elemento de alto nível, ou seja, oferecer acesso direto. Se for necessário que a forma de contato referencie o usuário ou o perfil, por exemplo, você faz uso de HATEOAS para isso.

Em resumo: arranque tudo da sua URL, deixe o que realmente importa. Os itens opcionais vão como query params e, se mesmo assim ainda faltar algo, reveja seu modelo. Deixe na URL apenas aquilo que realmente tem dependência hierárquica.

[]'s

1 curtida
#3

Obrigado pela atenção Alexandre, fico agradecido pela dica, nao conheço ainda o query param vou dar uma pesquisada e estudar sobre.

Qualquer coisa posto aqui o que encontrei, obrigado.

=]

#4

Alexandre Saudate, obrigado pelas dicas, conseguir resolver o problema de “diminuir” a minha url, digamos, “mais organizada”, como vc disse, @QueryParam foi a solução mais rapida e eficaz. A solução ficou mais ow menos assim:

[code]@Path("/materiaLegislativa")
public class MateriaLegislativaResource {

@GET
@Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
public Object getFiltro(@QueryParam(“numeroPagina”) Integer numeroPagina,
@QueryParam(“situacao”) Integer situacao,
@QueryParam(“numeroMateria”) String numeroMateria,
@QueryParam(“localizacaoAtual”) Integer localizacaoAtual,
@QueryParam(“relator”)Integer relator) {

    return MateriaLegislativaDAO.getInstance().getMateriaLegislativa(numeroPagina, situacao, numeroMateria,
        localizacaoAtual, relator);

}
[/code]

Para que estiver o msm problema, definir um valor caso nao seja passado na url, usei o @DefaultValue(“value”), e para fazer a requisição ao metodo a url no caso ficaria assim exemplo:
localhost:8080/SeuProjeto/materiaLegislativa?situacao=1&relator=2

Lembrando que é so um exemplo. :smiley:

E mais uma vez obrigado.

#5

Você disse no post Restful, e se for seguir essa linha, existe toda uma convenção da forma de criar a URL: recurso + acao + parametros na URL. Se vc tem query param, então não é REST…

Teria que ser algo como vc fez no início: SeuProjeto/materiaLegislativa/1/2/

E o mapeamento com @PathParam. No final, se vc estiver utilizando query param (com ?) ou embutido na URL, dá na mesma, mas todos são obrigatórios. Se pensar em recursos, vc expoe as possibilidades que o cliente do seu serviço irá consumir. Então uma forma seria mapear mais de um método com possibilidades de URL diferentes (e fazer uso da reutilização).

Lembrando que não está errado da forma final ae, mas se quiser dizer REST em um nível mais maduro, tem que seguir a convenção, além de utilizar os verbos HTTP, que no seu caso seria GET mesmo…




http://agilenomundoreal.com.br/2010/04/20/modelo-de-maturidade-rest/
http://agilenomundoreal.com.br/2010/04/13/videos-sobre-rest/

#6

[quote]Você disse no post Restful, e se for seguir essa linha, existe toda uma convenção da forma de criar a URL: recurso + acao + parametros na URL. Se vc tem query param, então não é REST…

Teria que ser algo como vc fez no início: SeuProjeto/materiaLegislativa/1/2/

E o mapeamento com @PathParam. No final, se vc estiver utilizando query param (com ?) ou embutido na URL, dá na mesma, mas todos são obrigatórios. Se pensar em recursos, vc expoe as possibilidades que o cliente do seu serviço irá consumir. Então uma forma seria mapear mais de um método com possibilidades de URL diferentes (e fazer uso da reutilização).

Lembrando que não está errado da forma final ae, mas se quiser dizer REST em um nível mais maduro, tem que seguir a convenção, além de utilizar os verbos HTTP, que no seu caso seria GET mesmo…




http://agilenomundoreal.com.br/2010/04/20/modelo-de-maturidade-rest/
http://agilenomundoreal.com.br/2010/04/13/videos-sobre-rest/ [/quote]

Não entendi o por que nao pode se dizer que é um REST em um nivel maduro, li artigos sobre:

http://docs.oracle.com/cd/E19776-01/820-4867/ghrst/index.html


http://www.mkyong.com/webservices/jax-rs/jax-rs-queryparam-example/

Qndo vc diz q todos são obrigatorios entendi +/-, sim minha aplicação precisa verificar tds, por isso isso o defautvalue.
Pensamos em deixar esses filtros em um metodo só para diminuir as chamadas ao servidor e assim melhorar o desempenho.

A da forma que eu estava fazendo nao estava legal, pelo fato de ter q passar tds os parametros de forma obrigatoria com o Pathparam, com o query nao preciso passar td,
e sim só o que vou usar somente.

#7