Making a Poor Man's Web Service

A "true" web service uses a robust and sophisticated structure.  Combining XML with SOAP and other goodies, you can unleash the power of the gods and melt down the entire Universe (or maybe just max out your NIC channel).  In any case, you can still achieve the same basic (repeat: Basic) capabilities using things like the old XmlHTTP object, or the .NET WebRequest object.

What for?

If you write scripts or do any programming, you may run into a situation where you would like to be able to pass a request to a web site via URL and get something back, without ever opening a web browser.

The old way, the "brute force" or "knuckle-dragging" way, was to open up the firehose and collect everything, the entire web page, into a bucket and sift through it. That is commonly called "screen scraping", but it's really just basic text or stream parsing.

With VBScript or KiXtart you can use the Microsoft.XmlHTTP object like this...

URL = "http://intranet.contoso.local/mypage.aspx"
Set objXmlHttp = CreateObject("Microsoft.XmlHttp")
objXmlHttp.Open "GET", URL, FALSE
objXmlHttp.Send ""
$result = objXmlHttp.ResponseText
Set objXmlHttp = Nothing

With PowerShell and .NET you can use the System.Net.WebClient object to do this.  Here is just one example...

$url = "http://intranet.contoso.local/mypage.aspx"

$wc = new-object System.Net.WebClient
$result = $wc.DownloadString($url)

Why bother?

The older you get, and the longer you work with programming, you eventually realize that you can leverage the power of existing structures without reinventing the wheel.  Let's say your best friend works in the web team and has a ASP, PHP, or ASP.NET web site that interacts with a database somewhere, maybe several.  Now let's say you're having lunch with this friend and you ask "hey, don't you have access to the hardware inventory system database?" and he puts down his sandwich and can of Red Bull and says "yes, why?"  "Oh nothing, it's just that I'd like to be able to query some information from it, but I can't wait for access approval from the DBA team."  After some more discussion you determine that the information you want isn't sensitive, but you don't really need to have the DBA folks setup a new DSN for you when your friend already has one for his apps.

Now your brain starts churning.  You think about all the pieces and what you can assemble.  What if your script, running on a remote desktop computer, could submit a query URL to a web page and get back some useful information for your script to continue on with?

What if you could fetch the computer name, or BIOS serial number, and pass that in like "http://intranet.local/computer.aspx?sn=ABC12345" and get back the Purchase Order (PO) number, and information about the warranty dates, service contract number, original owner, etc.?  Maybe your script could grab that, determine if the machine is still under contract support coverage, and go ahead and process an internal support request, or send an alert, based on some condition, all without ever popping up a form asking for user input?

$sn = "ABC12345"

$url = "http://intranet.contoso.local/computer.aspx?sn="+$sn

$filename = "c:\temp\filename.txt"
$wc = new-object System.Net.WebClient
$result = $wc.DownloadString($url)

# parse the contents of $result and do amazing things...

Get the picture?   Is this making sense yet?

You PowerShell nuts out there will obviously see where the above chunk of code can be refactored into a simpler form, but the point is what you can do with it.

This is ONLY ONE example.  Do not run with this and think I'm suggesting this is all it's good for.  There really is absolutely NO limit to where you can go with this.

As I say often:  Technological API's are like Lego building kits.  The more you have, the more you can do.

Ain't it awesome?