How will a Rest Service execute when a user access a resource from resource class?

Question

When multiple users are requesting the same resource method from a service class, how will requests be handled at the server?

How will a rest service execute for each request? How different the execution life cycle of rest service from the servlet execution?

For example, if below is the Resource, how will it be instantiated and executed in the following scenarios:

case 1: two users call the two different methods at a time

case 2: two users call the same method at a time

@Path("greet")
public class GreetingResource {

    @GET
    @Path("welcome/{username}")
    @Produces(MediaType.TEXT_PLAIN)
    public String sayWelcome(@PathParam("username") String User) {
        return "Welcome!" + User;
    }

    @GET
    @Path("hello/{username}")
    @Produces(MediaType.TEXT_PLAIN)
    public String sayHello(@PathParam("username") String User) {
        return "Hello " + User;
    }
}

Answer 1

Servlet classes

A servlet container creates a single instance of a servlet class to handle all the requests to that servlet. See the following quote from from the JSR 369 the defines the Servlet 4.0 specification:

For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration. [...]

The Servlet interface defines methods to initialize a servlet, to service requests, and to remove a servlet from the server:

• The servlet is constructed, then initialized with the init method.
• Any calls from clients to the service method are handled.
• The servlet is taken out of service, then destroyed with the destroy method, then garbage collected and finalized.

Don't hesitate to check the specification for further details.

Resource classes

While servlet classes are managed by the servlet container, resource classes are managed by the JAX-RS runtime. By the way, JAX-RS applications don't even require a servlet container to be deployed.

By default, resource classes (the ones annotated with @Path) are request-scoped. It means that the JAX-RS runtime will create a new resource class instance for each request to that resource. Quoting the JSR 370, the document the defines the JAX-RS 2.1 specification:

By default a new resource class instance is created for each request to that resource. First the constructor is called, then any requested dependencies are injected, then the appropriate method is invoked and finally the object is made available for garbage collection. [...]

According to Jersey documentation, in general this is unlikely to be a cause of performance issues. Class construction and garbage collection of JVMs has vastly improved over the years and many objects will be created and discarded to serve and process the HTTP request and return the HTTP response.

Also this makes for a very natural programming model where constructors and fields can be utilized without concern for multiple concurrent requests to the same resource.

EJB and CDI

For an implementation that supports EJB, resource classes can be annotated with @Stateless or @Singleton.

JAX-RS implementations may also support CDI however JAX-RS and CDI have slightly different component models. By default, JAX-RS resource classes are managed in the request scope, and no annotations are required for specifying the scope. CDI managed beans annotated with @RequestScoped or @ApplicationScoped can be converted to JAX-RS resource classes.

See the Java EE 8 Tutorial for examples.

Provider classes

Differently from resource classes, provider classes (the ones annotated with @Provider) are application-scoped by default. It means that the JAX-RS runtime will create only a single instance for each provider class. From the JSR 370:

By default a single instance of each provider class is instantiated for each JAX-RS application. First the constructor is called, then any requested dependencies are injected, then the appropriate provider methods may be called multiple times (simultaneously), and finally the object is made available for garbage collection. [...]

Answer 2

From Jersey documentation which is JAX-RS implementation:

Default lifecycle (applied when no annotation is present). In this scope the resource instance is created for each new request and used for processing of this request. If the resource is used more than one time in the request processing, always the same instance will be used. This can happen when a resource is a sub resource and is returned more times during the matching. In this situation only one instance will serve the requests.

From Life Cycle of JAX-RS Resource Class:

By default the life-cycle of root resource classes is per-request which, namely that a new instance of a root resource class is created every time the request URI path matches the root resource.

In short, following things happen in sequence.

Path’s are matched with Resource classes.
Constructor is called.
Dependencies are injected.
Appropriate method is called.
Resource is garbage collected.

Strangely, JAX-RS resource classes are not by default singleton. In general this is unlikely to be a cause of performance issues. Class construction and garbage collection of JVMs has vastly improved over the years and many objects will be created and discarded to serve and process the HTTP request and return the HTTP response.

While endpoint class is created new upon request by default, you can make it singleton to have one instance per JAX-RS application: JAX-RS Resource Lifecycle Performance Impact

Talking about your examples, in both case 1 and 2 instantiation wouldn't differ and users would use 2 instances of GreetingResource and get their name on return. In case 2, if the method would use database and 2 users would modify the same resource, you would need to manage concurrent access with optimistic locking or other solution.