Why should I use JAX-RS REST instead of normal servlets?

Question

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?

Answer 1

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.

STATELESS AND STATEFUL:

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.

IN A NUTSHELL:

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.

Answer 2

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

Answer 3

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