REST API with NIO?

Question

I have worked in the construction of a public API that will have a lot of concurrent accesses and one of the aspects that I thought is to use Asynchronous I/O to consider the scalability aspect.

Initially I thought in use Nginx as a HTTP Server (event-driven) because he work in async way, differently of Tomcat. The API will be constructed in Java and for that I thought in use the following components :

• Tomcat 7 - HTTP/Web Server + Java Container
• Netty.io or HttpCore?
• Resteasy (REST layer, w/ HttpServlet30Dispatcher servlet)
• MongoDB (w/ Async Java Driver)

I have seen many discussions about Servlet 3.0 because the new version has support to asynchronous requests (using NIO). Based in my problem and in the model above, I have some questions:

1. Is necessary to use Netty.io once that I have plans to use Servlet 3.0 that supports Asynchronous Requests too?
2. Use an event-driven webserver (ex: Jetty) is different to use a process based webserver like Tomcat 7 (that supports to Servlet 3.0) that isn't an event-driven webserver?
3. I saw in many sites that Netty.io works in a way where a thread can accept many requests, instead of the classic way of one thread peer request. In the practice, how it works?
4. Asynchronous request handing (Servlet 3.0) and Non-Blocking IO (NIO) are different concepts? In which way?
5. I never see a REST API using NIO, is it a good approach? Which potential problems can I will have?

Answer 1

Is necessary to use Netty.io once that I have plans to use Servlet 3.0 that supports Asynchronous Requests too?

No. It should all be handled by the container.

Use an event-driven webserver (ex: Jetty) is different to use a process based webserver like Tomcat 7 (that supports to Servlet 3.0) that isn't an event-driven webserver?

I'm not aware of any such difference. They both implement Servlet 3.0 so to that extent they are both event-driven.

I saw in many sites that Netty.io works in a way where a thread can accept many requests, instead of the classic way of one thread peer request. In the practice, how it works?

It's irrelevant, see (1) above.

Asynchronous request handing (Servlet 3.0) and Non-Blocking IO (NIO) are different concepts? In which way?

Yes. In every way. Too large a question to address here.

I never see a REST API using NIO, is it a good approach? Which potential problems can I will have?

I've rarely seen any need to use NIO at the client end.

Answer 2

I would say it's irrelevant to compare Servlet API and NIO. You can implement Servlet API using e.g. Netty (and that is very close to bicycle inventing). Taking into account async nature included into 3.0 I can't see it possible to build effective implementation based on blocking IO. We do not need even investigate sources. Class names like "org.mortbay.jetty.nio.SelectChannelConnector" are quite self-describing.

The same thing about REST. That is another layer. For example, you can setup tomcat to use NIO connector. Basically such configuration change will not be visible at application layer. (I do not consider bugs which sometimes happen).