Servlet vs RESTful
In my opinion, for a better understanding , we need to dissect components that confuse us and these components are ,
- REST Concept
Fielding used REST to design HTTP 1.1 and Uniform Resource Identifiers (URI)
- HTTP Protocol - Hypertext Transfer Protocol
javax.servlet.http.HttpServlet
class- REST with Java - JAX-RS and its implementations ( like Jersey etc)
- Other REST Implementations not conforming to JAX-RS ( like Spring REST ) Difference between JAX-RS and Spring Rest
Then if you refer this answer to understand as how these implementation use a Servlet ( A concrete javax.servlet.http.HttpServlet
) to intercept all incoming requests. Important quote there is,
These REST service classes are simple POJOs annotated to tell the jersey framework about different properties such as path, consumes, produces etc.
Then you can further read about - What is the difference between REST and HTTP protocols? & What is the difference between HTTP and REST? and make a conclusion as what advantages you get if you make your web service RESTFul , namely ( copied from one answer ) ,
REST is not necessarily tied to HTTP. RESTful web services are just web services that follow a RESTful architecture.
What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface
What is the advantage of using REST instead of non-REST HTTP?
Though, I wouldn't like to get into advantages - disadvantages ( pros & cons ) debate as that is very subjective.
With above readings , now for your question ,
What is the need for Restful services as normal servlet can also work on the HTTP methods?
You would understand that REST Frameworks simply simplify implementation of REST Services at enterprise level but they do use HTTP Servlet to intercept incoming requests. You can always use plain servlets to implement your own REST services but that would simply be more time consuming with lots of boiler plate code.
RESTful is more an architecture style than a different technology. In server perspective, it is designed to be entirely stateless and self-contained on a per-request basis (i.e. there are no sessions). In client perspective, it's more a way of getting information in different formats via URLs with (self-documenting) path parameters instead of request parameters.
Surely you can do this with a plain vanilla servlet, but it would introduce some boilerplate code to gather the path parameters and to generate the desired response. JAX-RS is just a convenient and self-containing API which removes the need for writing all the boilerplate code yourself, resulting in minimal and more self-documenting code.
Assuming that you've a JAXB entity as model as below:
@XmlRootElement
public class Data {
@XmlElement
private Long id;
@XmlElement
private String value;
// ...
@Override
public String toString() {
return String.format("Data[id=%d,value=%s]", id, value);
}
}
And a JAX-RS resource as below:
@Path("data")
public class DataResource {
@EJB
private DataService service;
@GET
@Path("text/{id}")
@Produces(MediaType.TEXT_PLAIN)
public String getAsText(@PathParam("id") Long id) {
return String.valueOf(service.find(id));
}
@GET
@Path("xml/{id}")
@Produces(MediaType.APPLICATION_XML)
public Data getAsXml(@PathParam("id") Long id) {
return service.find(id);
}
@GET
@Path("json/{id}")
@Produces(MediaType.APPLICATION_JSON)
public Data getAsJson(@PathParam("id") Long id) {
return service.find(id);
}
}
Then you'd already get the desired content in proper format by:
- http://example.com/rest/data/text/123
- http://example.com/rest/data/xml/123
- http://example.com/rest/data/json/123
That's it. Try to do the same with a single plain vanilla Servlet :) Please note that SOAP essentially also goes over HTTP. It's basically an extra XML layer over HTTP, not a different network protocol.
See also:
- REST tutorial
- JAXB tutorial
- Jersey tutorial