Question

I've developing a rest server that uses the Jersey libraries to implement the rest server functionality. I've not understand what is the life cycle of objects that I create in order to satisfy a client request. I'll try to explain in detail what is my doubt: supposing that a client request incomes, my server application creates a lot of objects (e.g. an array list containing a 10 objects, like property of another object), and finally returns this particular resource like a json message. Now, suppose that another equivalent (in every faceting) request incomes from the same client, does the objects already exists on the server? I've tried this scenario calling a particular method of a resource that increments a counter variable, and on every request it increases. Is the same for generics objects? Is the result the same supposing that multiple request incomes from different clients? A rest server could be stateless, but if it is, why the counter variable increases? Hope the I was clear on the problem explanation.

PS. I'm using Jersey 2.0 + Glassfish 4.0 + Netbeans 8.0 + JARX-RS directives.

Was it helpful?

Solution

What you should be doing is setting the cache-control header for responses you send to the client. That way, the client knows whether or not they need to go over the wire to get the data they want. You may also, if you think it prudent, use a server-side cache to save your server the database hit/object construction.

Jersey will let you set the cache-control header programmatically in ResponseBuilder.

If requests come from different clients, it's the server's responsibility to handle caching.

As far as the counter, I'm not sure what that has to do with statelessness. The REST architecture encourages that requests and responses be stateless. That doesn't prevent a server-side counter from incrementing, and it doesn't mean that nothing on the server will change. It just means that the server isn't tracking state from one request to the next.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top