@Controller com problemas na api rest

[Marcos Filho]

Não sei informar se é necessariamente um problema, mas vamos lá.

Normalmente crio DTO's para fornecer os campos de entrada na api rest. Quando crio um DTO com campos publicos para um POST, o json é convertido e setado corretamente nos campos.

Quando faço o mesmo em campos  com uma requisição @get em uma atribuição de objetos o mesmo dá problemas em erro no path.

Ex:
@Consumes("application/json")

@Get("/api/cartoes/{bind.idConta}/{bind.ult4DigCartao}")

public void visualizarDadosCartao(ReqCartaoDTO bind) {

...

}

só funciona se eu criar os getters/setters do dto.

não deveria funcionar também somente com os campos publicos ?

[Marcio Angelo Matté]

Bom dia Marcos, eu não sei se entendi, mas creio que a questão dos métodos de acesso para os atributos mesmo públicos devem ser criados, pelo fato de se utilizar os BEAN/POJO.

Internamente os frameworks invocarão os métodos set para atribuição de valores.

Peço desculpas caso eu tenha entendido errado a pergunta. Se puder, poste o método completo e o stack de erro! 

[]'s!

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vraptor+unsubscribe@googlegroups.com.
Para postar nesse grupo, envie um e-mail para caelum-vraptor@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/caelum-vraptor.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Marcio Angelo Matté
marcio...@gmail.com

[Carlos Spohr]

Bom dia marcos,

Eu geralmente crio algum objetos 'temporários' para vincular apenas aos métodos em que terceiros irão utilizar, eventualmente até uso casos em que a assinatura dos métodos terá Integers, Strings, etc...as vezes facilita a vida isso, principalmente se você está trabalhando sobre sistemas legados onde há uma estrutura que dificulte você usar todo o bom uso da OO.

Casos em que classes do bean/pojo, que por exemplo não tenham o método setId, baseado em alguma convenção, as vezes dão dor de cabeça na hora de você querer usá-los em métodos que não sejam do próprio framework de persistência por exemplo.

2017-06-05 9:58 GMT-03:00 Marcio Angelo Matté <marcio...@gmail.com>:

Bom dia Marcos, eu não sei se entendi, mas creio que a questão dos métodos de acesso para os atributos mesmo públicos devem ser criados, pelo fato de se utilizar os BEAN/POJO.

Internamente os frameworks invocarão os métodos set para atribuição de valores.

Peço desculpas caso eu tenha entendido errado a pergunta. Se puder, poste o método completo e o stack de erro! 

[]'s!

Em 5 de junho de 2017 09:52, Marcos Filho <m.fi...@gmail.com> escreveu:

Não sei informar se é necessariamente um problema, mas vamos lá.

Normalmente crio DTO's para fornecer os campos de entrada na api rest. Quando crio um DTO com campos publicos para um POST, o json é convertido e setado corretamente nos campos.

Quando faço o mesmo em campos  com uma requisição @get em uma atribuição de objetos o mesmo dá problemas em erro no path.

Ex:
@Consumes("application/json")

@Get("/api/cartoes/{bind.idConta}/{bind.ult4DigCartao}")

public void visualizarDadosCartao(ReqCartaoDTO bind) {

...

}

só funciona se eu criar os getters/setters do dto.

não deveria funcionar também somente com os campos publicos ?

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vraptor+unsubscribe@googlegroups.com.

Para postar nesse grupo, envie um e-mail para caelum-...@googlegroups.com.

Acesse esse grupo em https://groups.google.com/group/caelum-vraptor.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Marcio Angelo Matté
marcio...@gmail.com

--
Você recebeu essa mensagem porque está inscrito no grupo "caelum-vraptor" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para caelum-vraptor+unsubscribe@googlegroups.com.
Para postar nesse grupo, envie um e-mail para caelum-vraptor@googlegroups.com.
Acesse esse grupo em https://groups.google.com/group/caelum-vraptor.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Atenciosamente,
Carlos Alberto Junior Spohr Poletto

carlos.inf.br

[Marcos Filho]

Talvez não tenha sido tão claro no meu questionamento. Vamos lá.

Eu tenho objetos que são somente porta de entrada para meus serviços, conhecidos como DTO's. não vejo necessidade a criação de getters e setters nele (claro que há quem concorde/discorde) pois basicamente irei converter esses dados de entrada em minhas classes de negócio através de um mapper da vida.

O questionamento é que quando eu faço um @Post da seguinte maneira:

@Consumes("application/json")

@Post("/api/cartoes/desbloqueio/inicial")

public void meuMetodo(MeuDTO bind) {

...

}

Onde 

public class MeuDTO  {

public Integer campo1;

public String campo2;

public String campo3;

}

quando faço essa requisição, funciona perfeitamente, porém quando realizo um @Get do tipo:

@Consumes("application/json")

@Get("/api/cartoes/{bind.campo1}/{bind.campo2}")

public void meuMetodo(MeuDTO bind) {

...

}

no @Get nao permite iniciar pois ele informa erro na atribuição, permitindo somente quando eu crio os getters/setters.

@Marcio, não vejo necessidade o caso de toda vez ter que criar metodos getters and setters em DTOs sendo que os mesmos não irão encapsular nada, basicamente são utilizados para a transferencia de dados e posteriormente repassará os dados para uma classe do meu model (que possuirão seus respectivos getters/setters) e serão passadas para meus serviços que não conhecem meus DTO's.

resumindo em código.

Cliente cli = MeuMapper.convert(bind);

meuService.realizaProcedimento(cli);

--

Atenciosamente,
Carlos Alberto Junior Spohr Poletto

carlos.inf.br

--

[Marcos Filho]

@Marcio, estou sem poder simular agora o erro mas ao chegar em casa irei reproduzir novamente somente para informar a stack, mas basicamente o erro ocorre por não possuir os campos de getters/setters.

[Ivo Sestren Junior]

Ja tive esta situação e não funcionou também.

Resolvi criando os get's/set's.

Pelo que pude ver, o codigo no vraptor utiliza reflection para buscar os metodos de set para definir os valores, não funcionando quando tem acesso direto ao field.

Para postar nesse grupo, envie um e-mail para caelum-vraptor@googlegroups.com.

[Marcos Filho]

resolvi criando os getters e setters tbm porém fiquei curioso pelo fato do post funcionar o get não.

[Marcio Angelo Matté]

Então Marcos, como o Ivo falou, e eu também concorde, os frameworks vão utilizar os mecanismos de reflection para ler os atributos e invocar os devidos métodos assessores. Eu utilizo também uma abordagem parecida com a sua, em alguns casos crio alguns VO (Value Object) para enviar dados ou receber dados nas minhas API's REST. 

Existem diversos debates a cerca do tema (get/set) em VO/DTO, porém, acaba sendo uma convenção adotá-los. Depois de ter problemas resolvi padronizar todos os meus BEANS/POJO com getters e setters. 

É como no CDI a necessidade de um construtor padrão sem argumentos, não tenho certeza, mas parece que atualmente não é mais necessário, mas se vc fizer um teste, se criar um controller sem o construtor default ele não permite a injeção de dependência por constructor, ou algo do tipo. 

Resumindo, eu concordo com vc, talvez não houvesse mesmo a necessidade, quando não há o encapsulamento como necessário. 

[]'s!

[Marcio Angelo Matté]

PS.: acerca e não a cerca!

Marcio Angelo Matté
marcio...@gmail.com

[Marcos Filho]

Beleza @Marcio, entendi seu ponto de vista. No meu caso atualmente estou usando com os getters/setters só achei que deveria ser um padrão para os dois casos, o @POST e o @GET. No caso se houve erro no @GET deveria também ocasionar no @POST.

Mas obrigado pelo feedback de vocês.

Para postar nesse grupo, envie um e-mail para caelum-vraptor@googlegroups.com.

[Marcio Angelo Matté]

Sempre as ordens Marcos, e é bom compartilhar os problemas e/ou dúvidas, assim podemos melhorar a nossa maneira de codificar. Costumo dizer que não existe a bala de prata, mas da pra evoluir sempre! :-)

Abraços!