REST application design choices in a CDI world

Question

I have JAX-RS resource classes calling methods in separate service classes. I chose @RequestScoped for both resource and service classes so that I could easily supply (@Inject a common CDI instance) and pass the response back from the service class to the resource class.

The problem is that the service classes provide methods that would be useful to other classes with either @ApplicationScoped, @Dependent or @Stateless scope. But the injection of the response class no longer helps because there is no @RequestScope context for the backend classes.

I think I have a few choices

• Change the service classes to @Stateless or @Dependent and abandon using CDI to share a common response class instance, instead return a generic response from the service class that could be interpreted by any caller (not REST specific). This would be transformed into a REST response by the resource class.
• Create an additional layer by factoring out the bulk of the service classes into @Dependent classes that can be invoked from a @RequestScoped service layer or by the back end @Application/@Dependent classes.
• Something I haven't thought of yet

Could someone share how they might design such an application using CDI?

Answer 1

I am going to answer my own question.

The lure of using @RequestScoped seems to simplify the application design, but it's clear in the context of the bigger picture it adds complexity.

Adam Bien demonstrated that making your JAX-RS boundary classes EJBs (@Stateless) yields a better performance than @RequestScoped, so now the problem becomes one of passing results from the service layer back to the request layer or perhaps to another class that is not part of the boundary.

Eliminating the service classes completely and injecting control classes directly into the boundary is probably a better approach. The control classes could be @Dependant, @Stateless or @Application scoped (I presume?).

Also worth noting that @RequestScoped service classes wouldn't buy you anything anyway if you decided to create an alternative resource, e.g. a websocket API because that would not have the same @RequestScope as your service classes had either!