API/SaaS Wrapper - Sunday

Released! After a quick review Saturday with some changes and refactoring to whip my mega-methods into more manageable short chunks (thanks Jana!) it was ready to go. However at this time I don't want to open-source the code and I don't have a cohesive plan to market it. However if you're interested in testing it out or want to implement in your business please let me know, I'd be happy to provide a free trial in exchange for some feedback.

A few things that went better than expected

  • By Tuesday I had a working proxy of flickr's API. After that it was as simple as taking on a new set of features each day and polishing the others into something more consistent. For a project that seemed monumental at the start it came together surprisingly well.
  • I decided to open source a small project I put together Saturday morning to help with testing. It echos back some information on the request and allows you to specify what content type, status code and content you want it to echo back to you. Check it out on github http://github.com/pcorliss/Echo-Server
  • There was a slight issue with the initial configuration and setup. I ended up opting to spend my time coding instead of configuring so I fired up eclipse's Google App Engine (GAE) plugin and got started quickly. GAE apps are largely portable except for the memcache service which will need a small change to run on a different platform. This actually makes it a selling point for smaller startups because it means they could get up and running quickly without having to purchase servers or do much setup besides configuring a CNAME.
  • The project's market was murky at best at the beginning of the week. And I'm still not sure who I'll sell it to or if it would be better off being open sourced. I think it's definitely ready to be put into production, or at least into heavy load-testing. But I don't think setting up a server and running on a freemium model is the right plan at the moment.
Features Missed
  • After some thought I realized that output conversion isn't really something I would want if I or anyone else was building a public API. So it seemed reasonable to skip.
  • After a lot of reading it turns out I really didn't understand oauth all that well. Acting as an oauth provider or as a consumer for an API that sits in the middle doesn't really make sense. Perhaps in the provisioning portion, but that isn't practical since you'd have to interface with end points that aren't defined. By Thursday I had dropped the feature and moved on.