Monday, February 21, 2005

REST, SOAP, Email - Webservices the way it should be?

REST, SOAP, Email - Web services the way it should be?

I'm not exactly a web service Don or demi-god, or anything like that,
but I'm really a good programmer. I know what pains me when working on
projects, and what can help me get good results. Recently, I had to
build a device application that would work with a remote database to be
accessed via the web (naturally), and of course the word web services
poped up.

Long story short, I finished it. And during that course, i learnt some
important lessons. This weekend, I decided to read a bit more on
web services to try to close up any gaps in my knowledge, and some
interesting stuff has come out from that reading.

Instead of actually closing gaps in my knowledge, i have come to the
conclusion that what i need to know is not more SOAP/WSDL or XML-RPC,
etc, but what i actually need to know, is just more of my basic network
protocols, like PUT, DELETE, etc, (HTTP), MIME processing
(SMTP,POP,IMAP,etc), and other related stuff.

To get to this conclusion, these are the articles i came across thanks to
our big brother.... Google ;)

After reading all these articles, there seems to be a general consensus
that the way things were done earlier with Web-Services was inherently
wrong because of tight/close coupling. These days, it seems there is a
more to the document/literal paradigm when developing web services.
These also seem to have come about from the REST community making logs
of noise about lots of faults they found with SOAP et al.

I'm not going to repeat all those things, because first of all, i
haven't used SOAP really extensively to complain about it, but i do know
that the first time i actually sat down to think logically about the
concept of web services, the thing that came to my mind actually turns
out to be REST.

Its interesting to me because of the way i usually learn new concepts. I
believe that to a large extent, new concepts have subtle precursors in
things we already know. When i come across a new concept, i try to
relate it to something I've come across before, trying to get a rough
match, before i proceed. Sort of like being offered a new kind of fruit
and you go like, "Well... dunno if i'll like it, but lemme try...
mmmhh... tastes like Mango, only... a little... bleh.... ". Anyway, the
point is in relating to things in the most obvious ways.

Before my present job, I had worked in an Oil Servicing company, and one
of my projects, had been to build a low cost always present
communication system, complete with near-realtime status reporting. It
was an interesting project, and although I left the company before the
project was 100% finished, the idea was sort of novel in solution (i
think). The solution i came up with, was to use Phones, Email and the
Web. For these, the company acquired some satellite phones with ability
to send and recieve email. The remote worker would send email to a fixed
account, with specific subject line, to post information. The programs
would recieve the mail, probably send forward them to other quarters if
more action was needed, other wise, post them to a status website.
Questions to the remote worker could be sent via the website, or via job
specific email, and the programs would deliver them.

Why this example? Because, i see that simple scenario also as a web
service. Well... its email driven and all, but all the application is
doing, is sending data across resources accessed via known URI's (email
addresses in this case).

Scoot back to present. Without much of reading on Web services, I built a
webservice that looked just like the Amazon REST webservice (see the article above). How did that happen? Well... because that's
the natural way to think about Web services for anyone that has done even
the slightest amount of network or related programming. Of course, in my
case, i couldn't afford to pass XML message, since my device was limited
and bandwidth precious.

Combining the email and web scenarios above, leads me to think about TCP
against UDP. Connection oriented vs Non-connection oriented. I don't
know if its just me, but does any other person see these similarities.
The email based app i described above, didn't need to be in real time.
Results were generally expected in Hrs of requesting, so there was no
need to establish a connection and return results immidietly. In the
case of the device that needs to interact with a database, we need
results, right now, so we use HTTP. It just seems... natural for me to
think this way.

Now, i may be seriously short-sighted, and to this I admit, but I really
can't think of a problem that i can't solve with these methods (i am
classing EMAIL delivery as a non-connection oriented REST architecture).
It seems any other thing should just be a neccessary abstraction of
this, in forms of libraries to make these easier to do. Infact we
already have a wealth of opensource tools for dealing with most of what
we need. Wget, mailx, fetchmail, getmail, etc. There are also libraries
in almost any sane language you can think of to make these easy to achieve.

Without diving deeply into SOAP/WSDL, I've not yet seen what I'm
missing. Maybe its because I've never really been a fan of RPC. I just
don't like it. I prefer message passing, and not object passing and in
all my years of programming, I'm yet to see a scenario i couldn't
elegantly solve with message passing, that was also not simple.

Of course, I could be missing a point, but I'm yet to see it. I think
sometimes when "Software Architects", get together to come up with
ideas, they get carried away. Maybe it is because some of them have left
active coding for a while. They seem to look only at systems, and ignore
the easy (permit me to say lazy), truths which would be otherwise
obvious. The also ignore that sometimes, implementers/developers who
actually use these technologies, prefer transparent solutions that they
can hack at, and are easily layered on what is already simple, known and
proven. HTTP has that quality, EMAIL has that quality (what's more, the
GSM service - SMS, also has that quality). I always believe abstraction
should make transparent solutions a breeze to work with, not introduce
yet another layer you have to learn all about on top of what you already

In conclusion, Web services are here to stay, this is a given. Is the
future SOAPy or RESTfull? I don't know, I can't say. What i do know is
that REST is truly transparent and simple. Also, I hope that the REST
definition of Web services, should broaden to include such communication
channels as email and sms. This I think should be the next step of
Application development and delivery of information, even as our need
for information and our ability to communicate increases.

REST is very simple, as such, i don't see it fading away anytime soon.
The new direction SOAPy web services seem to be taking is also good and
somehow has the advantage of being transport mechanism agnostic.

What I say? 'tis all good :)


Post a Comment

<< Home