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

A chat service as a rest-ful api is a GOOD match !

I think resource-based interfaces are still a very important concept to talk about. The above answer is just not correct, even though it is over 4 years old.

In general, really NOTHING is wrong about building a chat server interface as an resource oriented ReST-ful API. It is absolutely valid and a very good match for the principle. There are even example and tutorial pages out there, that use this as a quite straightforward example to emphazise the intention behind ReST-ful API.

Why it is GOOD

It can be a forum like service or a "realtime" chat, it does not matter in this regard. It boils down to the domain model.

EXAMPLE 1 (classic realtime chat):

Be it a more elaborate chat service, then one needs to create a chat room. The chatroom will be attached to him/her (the user object) and the chatlobby enclosing it (just assumed). One can now either check the user resource or the chatlobby resource, or filter through chatroom resources via additional query-params, what is perfectly valid.

Which post the client has lately viewed and stuff like this, as long as it is not modelled in our chat service domain, is not part of the server state like mentioned in wikipedia. This is the "session" state of the client, the client tells which part of the collection of chat message resource it wants to GET.

So how dare one says that it does not match !! For the forum like chat it is even simpler.

EXAMPLE 2 (forum like chat):

A "chat" forumPost is a Domain Object aswell as a comment on this forumPost. Surely then they will need a unique identifier to allow for a unique resource identifier (URI). One can even see that this looks quite similar to the above example. It is generally a good example, however you want to turn the chat.

With an AOP audit you get created and modified times injected, can handle authorization ...

The core aspect is, that this kind of api makes it necessary to understand the domain and the fundamental parts that matter to the user, the consumer, or interacting applications in general.


It is really important to keep the principles in mind. The stated Wikipedia entry on ReST and the paragraph on STATELESS communication is aimed towards the client state, not the state of domain objects. Resources aka domain objects are by definition STATEFUL. The paragraph referenced is about session state, not domain state.

If you intend to develop enterprise software, it is crucial to keep the boundaries and rationales straight.


Comments and Posts, aswell as Users are perfect examples for a restful api. For this reason a chat service is absolutely fine to start with. Having a seqential identifier will definitely not hurt. Go further and try to use links for the relations (href) and define the relation via (rel) relation attribute. Then the client can use domain terms to consume the correct endpoints. The client can via this technique (HATEOAS) explore the entire graph of objects without any knowledge of the domain objects themselves.

Hope this helps to clarfiy, even though this is an older entry, the topic is still absolutely recent.

share|improve this answer
Yeah I ended up writing the chatroom as a RESTful API. It worked fine for me. I just represented the chatrooms as objects, and the messages as objects inside the chatrooms. – Jazzepi 2 days ago

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.