• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

[Query] Leonard Richardson and Sam Ruby

 
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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%]
*********************
 
author
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 78
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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%]
*********************
 
author
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Leonard Richardson
author
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 78
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic