What is the difference between a servlet and a restful webservice,in terms of 'can do' and 'cant do'.
I believe Restful WS dilutes a lot of the bootstrapping available with SOAP-based WS like QoS,state,security,contract etc.
Then what does it provide over a normal servlet?
What design criteria should decide that I prefer a Restful WS over a generic servlet-based web module?
Secondly,What would frameworkds like Jersey,Restlet provide over a generic servlet,except perhaps an ease of development.
The differences are very subtle for me - so would appreciate if someone had insights.
Wikipedia has a quite good article on REST: http://en.wikipedia.org/wiki/Representational_State_Transfer I recommend at least taking a look at the key goals and constraints section.
REST is an architectural principle; by adhering to the constraints, one can reach the (key) goals.
You can do whatever you want to do, but if you do not adhere to the constraints then you will be less likely to reach the goals.
Leon Omk wrote:For me, restful web service is just "annotated" servlet, accepting http request and replying http response!
REST is based on using all HTTP methods -which include PUT and DELETE-, so thinking about REST in terms of servlets -which almost exclusively use GET and POST only- does not get at their full capabilities, nor at the actual RESTful architecture style.
And does resful web service provide "java client"?
The service is a service, not a client. Any particular REST implementation -like Jersey- may provide tools or APIs for accessing REST services (and Jersey does so).