Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm teaching myself J2EE technologies using Glassfish as my webserver and EJB container. I'm very interested in learning REST as well, and developing an application that is adherent to the rules of REST.

My first project is to write a chat client. The user will go to a webpage, download a webpage with the javascript to run the chat client (which posts the data to the server and fetches it as well). The calls to post data, and to fetch data, from the webserver will be through a RESTful interface. Right now I've done this through servlets that listen on the /chatroom/getMessages and /chatroom/postMessage URI's.

The wrinkle that I run into when I try to convert this to a RESTful service using JAX-RS that doesn't use servlets is that I feel like I'm reinventing the wheel. With the servlet specification I had this HTTPSession object that made it very easy to keep track of where someone is in the chat buffer (and therefore which messages should be sent to them when they visit /chatroom/getMessages). But now when I make it completely RESTful, and just use POJOs with JAX-RS (which I actually like better from a style standpoint) I now have to reinvent session state if I want it by handing the person a token, and having them hand it back to me every time we talk just like the automagically generated session cookie would have done for me if I was using servlets.

WHY should I implement this with JAX-RS and abandon the servlets? I haven't seen any JAX-RS tutorials that mix servlets and JAX-RS (probably for good reason), so this doesn't seem to be an option. What I really want to know is what compelling reasons there are for going with REST. What does it buy me to not just use the servlets in a RESTful way?

share|improve this question
up vote 0 down vote accepted

Having implicit session state in the server runs against the basic concept of REST:

The client–server communication is further constrained by no client context being stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and any session state is held in the client. The server can be stateful; this constraint merely requires that server-side state be addressable by URL as a resource.

I don't think a chat client fits the REST architecture well. If you want to do it anyway, you should try to make the "position in the chat buffer" a part of the REST URL (e.g. by giving messages an incrementing id, and the client calls /chatroom/5/getMessages/37 to get all messages in chatroom #5 after message #37

share|improve this answer
I'm not sure why this isn't a good candidate for REST. Couldn't you imagine a simple chatroom as a pretty popular SOA service? When you say "every message after message #37" it seems like you're implying that as people post messages that number will grow ad infinitum (along with the memory or db table to keep each message in storage for retrieval). I think you'd have a good chance of running out of memory. The reason I wanted to have state is to keep track of who hasn't heard parts of the conversation that they're entitled to while timing those people out over time. – Jazzepi Feb 13 '12 at 16:53
Running out of room here. But the basic idea would be to hold a single chat history with each person having an index into the chat where that index is managed by the server, not by the client. When someone asks for more messages, any messages past their index in the queue would be given to them, and then the server could check to see if there are messages which no one is waiting on, delete them out of the global queue, and then possibly adjust pointers. – Jazzepi Feb 13 '12 at 16:55
I guess if I'm willing to I can simply expire messages out of the queue after a certain amount of time living there. That might be a simple solution and still be able to use the REST style call you're talking about. – Jazzepi Feb 13 '12 at 16:59
@Jazzepi: If there is any chance of a DB table running out of memory when storing text messages typed by humans, then you are doing something very, very wrong. And no, a chat client is not a fitting example for a SOA service, because SOA is about integrating complex business services. And it's not a good candidate for REST because REST is about making individual domain objects accessible via HTTP URLs. It's only a fit if you make each chat message a domain object, which is what I described. – Michael Borgwardt Feb 13 '12 at 17:01
Alright, thanks for the advice. I'll try to give this a shot. – Jazzepi Feb 13 '12 at 17:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.