I am really curious to know what goes inside the book "RESTful Web Services"!!
I have recently cleared SCDJWS examination and have been working with Web Services for a couple of years now. Many a times while developing web services I find it necessary for the service to store some state of the client and we usually deploy WebServices in a clustered environment, So will RESTFul Services take off some of my burden? or is it just transfer of state using a Transfer protocol like HTTP?
REST doesn't really say how to get client state off of the server; it just tells you not to put it there, so you can run your service on a bunch of dumb load-balanced servers. How to get to that point depends on your situation, and it might not be possible with what you need to do. Here are a couple ideas. (Keep in mind that I speak as a recognized non-expert in this field.)
If you don't trust the client with the state because the client might "cheat" by modifying it, you can encrypt the state before giving it to the client, though this is a little sleazy.
If the state really must stay on the server for whatever reason, the best thing to do from a RESTful standpoint is to expose that information as a resource. In the terms used in RWS, you change it from application state to resource state. Give it a URI so the client can access it, and store it with the rest of your resource data. All your load-balanced machines will get it from the same source, which means they can stay dumb and not have to communicate with each other.
Now, this might or might not ease your troubles--it might just mean you have to cluster your database instead of your web servers. However, I think database clustering is easier, and gives more general benefits.
Joined: Mar 21, 2006
Thanks for your viewpoint!!
Presently, We have a SOA in place comprising of n-number of Web Services, exposed by their SEI and WSDL's, So whenever we get a request from an external client we expect the client to send in the Authentication SOAP MIME Header along with the SOAP Body, which we decrypt in the Message Handlers and justify one's right to use the resource requested for.. So this all is possible because we are using SOAP Based web service.
If we modify our architecture to expose all the services as resources, with just a URL for communication via GET, POST, Will It be possible to do a similar kind of Authentication that I talked off in my previous stanza.
Hope I am clear enough in expressing myself, and I get "one good" reason to migrate to RESTFul Services?
Dinesh, if you go to a site on the web that involves purchasing an item using a credit card, you will often see the url change from to . What that means is that the web request is being sent over a secure socket. On top of that you can use your choice of HTTP authentication mechanisms, though with a cryptographically secure socket, many find that basic HTTP authentication is sufficient.
Is that a good reason to migrate? That's not so clear. What I am saying is more along the lines of: given that there are other reasons to switch, use of https can help with your encryption requirements.
Joined: Jun 08, 2007
Dinesh, I'm by no means a SOAP expert, but I don't see why you need to keep any state on the server in your existing setup. The client is sending authentication with every request, right? Do you do something like limit the number of requests a given user can make in a day?
As Sam says, an HTTP client can send authentication credentials in the request header "Authentication". There are a variety of authentication mechanisms, and it's extensible, so you can plug in custom credentials if you need to. But as Sam says, HTTP Basic authentication is usually fine, when combined with HTTPS.
Joined: Mar 21, 2006
Hi Leonard, I get your point.
We indeed have such a requirement to maintain the state for some Single Sign ON (SSO) purpose and we are sending the Authentication information in the header!!
But leaving apart all this security design, the RESTFull Web Services takes us back to where it all started - the World Wide Web (WWW). So we expose our operations as resources on the web accessile by URL's using our old friend - HTTP. So are we completely eliminating RPC calls to the Service or RPC-Procedures would be used as a complement to the RESTFull Services?
Dinesh, it's theoretically possible to to completely get rid of RPC-style use of HTTP and expose everything through GET/POST/PUT/DELETE resources. In real life, this is sometimes more trouble than it's worth. I think there is a place for the RPC style, and the HTTP standard explicitly allows for it. But right now the balance is too far towards the RPC end.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com