The Site Formerly Known as Bit Working This site has moved to http://bitworking.org

The chickens have come home to REST

I was really hoping to avoid the whole REST debate. I only caught pieces of it from some of the SOAP people in my blogroll. It seemed rather esoteric and just not really related to my daily life, either at work, on BitWorking, or on Aggie. Now I am paying the price for sticking my head in the sand as I just got hit in the face with a RESTian issue in Aggie.

Here is the setup. Aggie is a .NET GUI application. It is not a web server, like Radio or AmphetaDesk for example. When the news has been formatted Aggie just launches the browser with the file off the hard-drive. I liked this approach better because I didn't like the complexity and security issues that embedding a web server into Aggie might preset. ( This is not a rub against Radio or AmphetaDesk. Having the web server solves a lot of problems, one of which I am facing now. )

The problem arises when I want to get some communication FROM the web browser TO Aggie. Two examples:

1. I could parse each item and do some RSS Auto-Discovery and list the 'found' RSS feeds at the end of each item. The ultimate convenience would be to make a link for each 'found' RSS feed and when you clicked on the feed it was automatically added into your channels list in Aggie.
2. The other scenario would be a post-to-blog action that pushed the item into your weblog software ready to be annotated and published.

To do either of these I need to communicate from a static web page back into Aggie. I would traditionally reach for my SOAP tool to solve this problem but then realized that I can't send a SOAP message from this static web page, or more precisely, I cannot generate a SOAP call via POST from a static web page. (That slapping sound was my head hitting REST.) So now I go back and read some recent articles on REST including Hyperlinks matter and TAG Finding: URIs, Addressability, and the use of GET I think I just hit some kind of RESTian ah-ha. I can encode all the info into a GET request and this would work from a web page read off the local hard-drive. The formatting of the data is irrelavent, it could be a SOAP message encoded into a GET request, the important part is that it is all part of the GET request. Yes, this does require me to implement a partial web server. I have to listen on a TCP/IP port and parse incoming GET requests and convert them into appropriate actions in Aggie. So if I still call up Aggie.html off the hard-drive, and you squint, and fuzz your eyes, and promise not to look too hard, it won't really look like a web server... Oh well, at least I learned about the importance of URL's and GET.

Aggie License

... The hardest part is finding something done w/ the right license; I'm not wild about GPL.[The .NET Guy]

Not a worry there, I chose the MIT License for Aggie.