Java – how does caching work in jax-rs?

Suppose I use the @ get method to make the following web service calls:

@GET
@Path(value = "/user/{id}")
@Produces(MediaType.APPLICATION_JSON)
public Response getUserCache(@PathParam("id") String id,@Context HttpHeaders headers) throws Exception {
    HashMap<String,Object> map = new HashMap<String,Object>();
    map.put("id",id);
    sqlSession session = ConnectionFactory.getsqlSessionFactory().openSession();
    Cre8Mapper mapper = session.getMapper(Cre8Mapper.class);

    // slow it down 5 seconds
    Thread.sleep(5000);

    // get data from database
    User user = mapper.getUser(map);

    if (user == null) {
        return Response.ok().status(Status.NOT_FOUND).build();
    } else {
        CacheControl cc = new CacheControl();
        // save data for 60 seconds
        cc.setMaxAge(60);
        cc.setPrivate(true);
        return Response.ok(gson.toJson(user)).cacheControl(cc).status(Status.OK).build();
    }
}

To experiment, I slow down the current thread five seconds before getting data from the database When I use Firefox poster to call my web service, it looks faster in 60 seconds, in the second, third call, etc., until 60 seconds However, when I paste the URI into chrome, it seems to slow down by 5 seconds at a time I'm really confused about how to use this technology to implement caching This is my question:

>The poster will actually see the maximum time of the header and decide when to retrieve the data? > On the client (web, Android...), When accessing my web service, I need to check the title and then perform caching manually or the browser has cached the data itself? > Is there any way to avoid getting data from the database every time? I think I will have to store my data in memory, but may it run out of memory? > In this tutorial, jax-rs caching tutorial: how does caching actually work? The first row always gets data from the database:

Book myBook = getBookFromDB(id);

So how is it considered caching? Unless the code is not executed in the up / down order

@Path("/book/{id}")
    @GET
    public Response getBook(@PathParam("id") long id,@Context Request request) {
        Book myBook = getBookFromDB(id);
        CacheControl cc = new CacheControl();
        cc.setMaxAge(86400);
        EntityTag etag = new EntityTag(Integer.toString(myBook.hashCode()));        
        ResponseBuilder builder = request.evaluatePreconditions(etag);
        // cached resource did change -> serve updated content
        if (builder == null){
            builder = Response.ok(myBook);
            builder.tag(etag);
        }
        builder.cacheControl(cc);
        return builder.build();
    }

Solution

From your question, I can see that you are mixing client cache (HTTP) and server cache (database) I think the root cause of this is the different behavior you observed in Firefox and chrome. I'll try to clear this

Example:

@Path("/book")
    public Response getBook() throws InterruptedException {
        String book = " Sample Text Book";
        TimeUnit.SECONDS.sleep(5); // thanks @fge
        final CacheControl cacheControl = new CacheControl();
        cacheControl.setMaxAge((int) TimeUnit.MINUTES.toSeconds(1)); 
        return Response.ok(book).cacheControl(cacheControl).build();
    }

I have a quiet web service running and URL for this

http://localhost:8780/caching-1.0/api/cache/book - GET

FireFox：

The first time I visit the URL, the browser sends a request to the server and returns it with a cache control header

The second request takes 60 seconds (using carriage return): at this time, Firefox does not go to the server to get a response, but loads data from the cache

Third request after 60 seconds (using carriage return):

This time Firefox asked the server to get a response

Fourth request using refresh (F5 or Ctrl F5):

If I refresh the page (instead of pressing enter), in the request 60 seconds ago, Firefox did not load data from the cache, but requested the server and special header in the request

Chrome：

The second request takes 60 seconds (using carriage return): at this time, chrome sends a request to the server again instead of loading data from the cache, and adds header cache control = "Max age = 0" to the request

Aggregation results:

Due to different chrome responses, you can see different behaviors in Firefox and chrome by typing and clicking. It has nothing to do with Jax rs or your HTTP response The summary client (Firefox / Chrome / Safari / Opera) will cache the data of the specified time period in the cache control, and the client will not send new requests to the server unless the time expires or until we force a refresh

I hope this clarifies your question 1,2,3

The example you mentioned is not about minimizing database calls, but about saving bandwidth through the network. If the data is not updated, the client already has the data, checks the server (Revalidation), and resends the entity