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?

3 Answers 3


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.

  • 1
    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
    Jun 29, 2016 at 11:39

Note: webservices are high level to servlets

Even though we can write services through servlets, using webservices we can write services in structural way easily.

There are two flavours of webservices 1) SOAP based 2) RESTful webservices.

Difference between servlets and soap based webservices: i) these webservices can't be directly accessed through browser. ii) We need not to write webservices prototype separate, which is generating wsdl(which describes webservices using xsd), it can be published to consumers of webservices iii) soap ws are introduced to easily support SOA(Service Oriented Architecture)

Difference between servlets and restful webservices: i) Even though restful webservices directly works on http/https protocal, it provides some other web methods in addition to get, post are put, delete. Which allows to write db operation based structured code easily. ii) As restful webservices allows for pathparameters apart from query parameters, we can easily write class level and method level convenient operations-code. iii) we can use postman like browser plugins to easily check rest-api’s. We can easily add headers, body parameter, selecting different methods, content type along with request to required restful webservice under an URL. iv) we can also provide security to rest-webservices easily through header section of http request msg's


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

  • 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, 2012 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, 2012 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, 2012 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. Feb 13, 2012 at 17:01
  • Alright, thanks for the advice. I'll try to give this a shot.
    – Jazzepi
    Feb 13, 2012 at 17:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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