wood burning stoves 2.0*
The moose likes Web Services and the fly likes [Query] Leonard Richardson and Sam Ruby Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "[Query] Leonard Richardson and Sam Ruby" Watch "[Query] Leonard Richardson and Sam Ruby" New topic
Author

[Query] Leonard Richardson and Sam Ruby

Dinesh Sundrani
Ranch Hand

Joined: Mar 21, 2006
Posts: 78
Hi Leonard Richardson and Sam Ruby,

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?

*********************
Regards,
Dinesh Sundrani
---------------
SCJP 1.5 [86%]
SCWCD [95%]
SCDJWS [98%]
*********************
Leonard Richardson
author
Ranch Hand

Joined: Jun 08, 2007
Posts: 37
Dinesh,

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.
Dinesh Sundrani
Ranch Hand

Joined: Mar 21, 2006
Posts: 78
Hi Leonard,

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?

*********************
Regards,
Dinesh Sundrani
---------------
SCJP 1.5 [86%]
SCWCD [95%]
SCDJWS [98%]
*********************
Sam Ruby
author
Greenhorn

Joined: Jul 23, 2003
Posts: 13
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.


Sam Ruby
Leonard Richardson
author
Ranch Hand

Joined: Jun 08, 2007
Posts: 37
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.
Dinesh Sundrani
Ranch Hand

Joined: Mar 21, 2006
Posts: 78
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?

*********************
Regards,
Dinesh Sundrani
---------------
SCJP 1.5 [86%]
SCWCD [95%]
SCDJWS [98%]
*********************
Leonard Richardson
author
Ranch Hand

Joined: Jun 08, 2007
Posts: 37
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 agree. Here's the link: http://aspose.com/file-tools
 
subject: [Query] Leonard Richardson and Sam Ruby
 
Similar Threads
[Query on ROA] Leonard Richardson and Sam Ruby
Winners: RESTful Web Services
[Query on ROA] Leonard Richardson and Sam Ruby
[Query on ROA] Leonard Richardson and Sam Ruby
RESTful interoperability