Solucionado (ver solução)
Solucionado
(ver solução)
2
respostas

Controller ou Resources - Comparação com Spring

Boa noite.

Eu que vim do Spring estou com dificuldades para entender alguns conceitos. Nesse vídeo excluímos nosso Servlet e criamos outra classe chamada AgendamentoEmailsController. Usamos essas nomenclatura do Controller, segundo o professor em alguns lugares costumam chamar de Resources. Nesse controller utilzamos os benefícios do JAX-RS. Eu não consegui entender:

1 - Esse nosso AgendamentoEmailController continua sendo uma Servlet mesmo não estendendo ou implementando nada referente a servlets? Porque no Spring os Controllers são onde temos as nossas ações, não são servlets. No Spring temos um Dispatcher Servlet que "chama" esses nossos controllers. Mas até aqui no curso, mesmo agora com o JAX-RS, não temos nenhum uso de um servlet central né? Como é feito no Spring. Portanto toda classe @Path com JAX-RS que eu criar será um novo servlet, não tendo os benefícios de uma única entrada servlet. Existe isso(Dispatcher Servlet) no Java EE juntamente com o JAX-RS?

2-

package br.com.alura;

import javax.ws.rs.ApplicationPath;
import javax.ws.rs.core.Application;

@ApplicationPath("/")
public class AgendamentoEmailApplication extends Application {

}

Essa classe estendendo Application é somente uma classe de configuração? É basicamente para registrar, identificar o caminho da aplicação e configurar (se necessário) todas as nossas classes JAX-RS anotadas com @Path? Pelo que entendi, como não estou sobrescrevendo nenhum método de Application, por default ele varrerá meu classpath e registrará automaticamente os meus JAX-RS.

Supondo que tenho que criar mais uma classe JAX-RS anotando com @Path, então não preciso criar mais uma classe estendendo de Application, correto? Essa outra classe seria necessário somente se eu tivesse que registrar ou configurar ela de forma diferente, como por exemplo alterar o @ApplicationPath, que fica entre o contexto e o recurso. O AgendamentoController continuaria com o "/" e minha nova classe poderia ficar em "/api" (localhost:8080/agendamento/api/emails).

Muito obrigado. O curso está maravilhoso, parabéns.

2 respostas
solução!

Eduardo, bom dia. Vamos lá, vou tentar responder a todas suas perguntas.

1 - Esse nosso AgendamentoEmailController continua sendo uma Servlet mesmo não estendendo ou implementando nada referente a servlets? Porque no Spring os Controllers são onde temos as nossas ações, não são servlets. No Spring temos um Dispatcher Servlet que "chama" esses nossos controllers. Mas até aqui no curso, mesmo agora com o JAX-RS, não temos nenhum uso de um servlet central né? Como é feito no Spring. Portanto toda classe @Path com JAX-RS que eu criar será um novo servlet, não tendo os benefícios de uma única entrada servlet. Existe isso(Dispatcher Servlet) no Java EE juntamente com o JAX-RS?

  • Na verdade o JAX acaba sendo uma abstração das servlets, por debaixo dos panos, essa comunicação ainda será feita como nós vimos no começo do curso. No Spring temos as @RestControllers, junto com as anotações @PostMapping, @GetMapping e esse conjunto de anotações serve para abstrair códigos de mais baixo nível.

2 - Essa classe estendendo Application é somente uma classe de configuração? É basicamente para registrar, identificar o caminho da aplicação e configurar (se necessário) todas as nossas classes JAX-RS anotadas com @Path? Pelo que entendi, como não estou sobrescrevendo nenhum método de Application, por default ele varrerá meu classpath e registrará automaticamente os meus JAX-RS.

  • É exatamente isso, uma classe de configuração. Sem essa classe, seus recursos JAX não serão reconhecidos. Você pode fazer um teste, não criar essa classe e tentar fazer requisição para seus controllers/resources e verá que não funcionará. Em stacks como o Quarkus, não é necessário criar essa classe.

3 - Supondo que tenho que criar mais uma classe JAX-RS anotando com @Path, então não preciso criar mais uma classe estendendo de Application, correto? Essa outra classe seria necessário somente se eu tivesse que registrar ou configurar ela de forma diferente, como por exemplo alterar o @ApplicationPath, que fica entre o contexto e o recurso. O AgendamentoController continuaria com o "/" e minha nova classe poderia ficar em "/api" (localhost:8080/agendamento/api/emails).

  • Não é necessário criar mais uma classe que estende de Application. Existe apenas uma que servirá para todos os controllers ("Por isso ela fica em um nível/pacote acima dos demais). Na subclasse de application você pode definir um path que ficará entre o contexto e o recurso (comum a todas as chamadas) e no @Path você declara o seu recurso (específico).

Se ficou faltando algo, manda ai que a gente tenta resolver!! haha =)

Obrigado João Victor.

Referente a um servlet central no Java EE, o próximo curso da formação que é sobre JSF aborda o tema.