The basics of REST API is, all request received in a common gateway , read this request and map it to a Java class. This we can do using pure Java servlet with the help of some custom Interface. So we can avoid boilerplate code and reflection right?
Use a framework, don't invent your own based on pure servlets.
Don't worry about performance problems because some frameworks might use reflection. You don't know if they are using reflection (or did you look in the source code of those frameworks?). Also, even if those frameworks really were using reflection - reflection is not so awfully slow that you need to avoid it at all cost. There is no reason to worry about performance based on vague worries about reflection beforehand.
These are well-known frameworks that are used by lots of businesses. These frameworks have proven themselves already.
Creating REST webservices based on pure servlets is much more work and much harder to get right than using a framework which already puts the basics in place for you.
First: Don't use too much bolding in your posts. It comes across as shouting!!! - and I'm sure you didn't intend that.
Vs Prasanth wrote:But these frame works are using Java reflection to a large extent right?
No idea; but I suspect they may use some.
Will this cause any performance issues when the project becomes bigger and when lots of hit goes to the server?
Not your problem - And the reason I put that in bold is because it's very important.
You are presumably using (or buying) this framework precisely because you don't have to write the code yourself.
And if you bought it, you presumably also have an SLA that covers concerns like this.
If not, and you're worried about it, the best people to address this question to is the authors.
However, in general, and assuming the product is good, you can usually trust them to make sure that their software scales well - especially with something like REST - otherwise they'd be out of business pretty darn quickly.
So my advice:
1. Don't go looking for problems before they occur ... especially when it comes to optimization/efficiency.
2. As Jesper said: DON'T re-invent the wheel - especially as an "end-around" to a problem that you don't even know exists.
You bought/adopted the product for a reason. Use it the way the authors tell you to.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop