Which statement is true about JAX-RS resource implementation?

Question

Options

• AThe REST resource implementation class must extend the javax.ws.rs.core.Application class
• BThe REST resource class can be implemented as a stateful Enterprise JavaBean (EJB).
• CThe REST resource class can be implemented as a Plain Old Java Object (POJO).
• DThe REST resource implementation class must not be final.

• A
  79% (27)
• B
  3% (1)
• C
  6% (2)
• D
  12% (4)

Explanation

Note: The provided answer key appears to contain an error. Option A is actually false - and C is the correct answer.

Option C is correct because JAX-RS was specifically designed so that resource classes require no special superclass or interface; any ordinary Java class annotated with @Path (and method-level annotations like @GET, @POST, etc.) qualifies as a JAX-RS resource. This POJO-based approach is the fundamental design principle of JAX-RS.

Why the others are wrong:

• A is false: javax.ws.rs.core.Application is used to configure the JAX-RS application itself (registering resource classes, providers, etc.), not to implement resources. Extending it in a resource class would be a misuse of the API.
• B is false (or at least misleading): While stateless session EJBs and singletons can serve as JAX-RS resources in Java EE, stateful EJBs are not supported as JAX-RS resources because JAX-RS manages resource lifecycle independently and cannot maintain EJB stateful session state across HTTP requests.
• D is false: The JAX-RS spec does not prohibit final resource classes, though certain proxy-based implementations (e.g., Jersey with CDI) may struggle with them in practice.

Memory tip: Think "JAX-RS = Just Annotate your X (class)" - no inheritance required, just add @Path to any plain class.

No community discussion yet for this question.