I'm like a newbie all over again... I've kept up a little bit on the buzzwords, etc... but haven't had to actually implement anything from scratch in more than 12 years. I figured surely in the meanwhile all of this stuff would be sorted out, and there would be a nice standard way to have programs talk to each other across the internet.
So now I know what all of those buzzwords like SOAP, XML-RPC, REST, WDSL and the rest mean... nobody has a nice simple way to do things...
I was hoping to do a nice simple demo of a RESTful capabilities system using Python as a simple standalone app that anyone could just put on their PC (or server). It turns out that there are several things in the way. Here are some of the things I've learned.
- Cryptographic random number routines aren't included in python. (Dean Landolt suggests punting the issue and getting on with it... and I agree for the demo)
- The library that would do it requires me to be able to re-compile python (using Visual Studio 2003)
- REST isn't... the common example of Flickr as a RESTful API isn't.
- WDSL is for people who like to write specification specifications, and don't write code.
- REST is the choice, except that web browsers don't actually PUT or DELETE, and a lot of people use GET for things with side-effects.
- There are a lot of python web toolkits out there, including CherryPy, TurboGears, Web.py, Django, and others.
In spite of all that, here are my design choices to date:
Programming language: Python, because it's cross platform, a known entity, and quite powerful, despite the immutable strings, and comes with a web server library.
Database: None - it's a demo
Random Salt: the built in non-secure RNG from python
Protocol: REST-ish... GET for reading, idempotent operations only, POST for everything else. Rest because there should only be one URL per object, regardless of the compromise about PUT/Delete.
The demo will be of the ability to edit a string. You'll be able to see the string with a straight web page. You'll be able to request a token to edit the string, you'll be able to write the string (provided you have the token) and you'll be able to revoke the token.
I'm hoping that's simple enough for me to get done on a few train trips to/from work.
1 comment:
Ah yes, the thrilling, mind-numbing world of architecture choices. I can't tell you how much time I've sunk into dissecting the minutia of all these different decisions (and typically paralyzed myself on all my hobby projects because of it)...
As far as ReSTfulness -- GET and POST is ReSTful enough, and anybody telling you otherwise is being as much a purist as the very same SOAP folk they belittle.
As for database choices, you don't have to worry about that -- SQLAlchemy will pretty much take care of all that for you whenever you're ready for persistence.
Web frameworks. You mentioned TurboGears and CherryPy, but TurboGears 1 is actualy built on top of CherryPy. You left a few off the list -- Grok is pretty interesting, and Pylons is quite popular. I'm trying to learn it now as it's what's under the hood of TurboGears 2 (and I know the guys in lording over those two frameworks are on the ball!).
I haven't tooled around too much with the others, but frankly that's the beauty of the WSGI standard -- at the lower levels they're all the same, or getting very close.
If you can get the interface figured out I'd be happy to help you with the web stuff.
Post a Comment