Most of my experience as an ex-sysadmin with web services is with SOAP. And I couldn't speak about experience; the only thing I had to do back in these days was to setup Tomcat and Axis to host mysterious "SOAP" applications.
As soon as I started reading the manuals of Tomcat and Axis at each of these installations, I quickly ran away -- not only couldn't I understand anything, but these docs all started with the idea that whoever was reading them had a strong knowledge of Web Services and/or Java. Which, of course, I didn't.
At a high level, I understand what SOAP is. But since I've jumped in system architecture, what I've been hearing recently is this:
"We're modeling our web services architecture on REST".
Oh no, not a new buzzword. Wasn't SOAP complex enough? What the heck is REST?
Fear no more. It turns out REST has been out there for a while. A long, long while. On the web before many didn't know what the web was.
Anyone who knows the basics of HTTP will understand REST quickly. REST is not a heavy, XML-based protocol as in SOAP. It's a way of doing things the simple way, using straight HTTP to transfer information in - sorry if I interpret things little too much here - an ad hoc manner. No freaking XML and standards. Thus, your web browser is a REST client. If you want to go a little more deeper, another example would be Amazon's S3 which is a more complex service based on REST. In fact, if a service doesn't use SOAP, it probably uses REST.
REST is how anyone with a good-enough basic knowledge of HTTP, but doesn't give a shit about XML and layered protocols, will natively think web services should work. The way things should be. I'm hardwired to think this way, and SOAP always had me thinking that it was way overkill for a lot of uses.
I'm currently reading the following tutorial:
http://rest.elkstein.org/
Go read it, it is very well written.
Also take a look at the comment page here. Dr. Elkstein gives there a rough comparison between RPC, SOAP, REST.
O.
No comments:
Post a Comment