I have noticed a trend with regards to API/ Web service design, mostly from those where the API has been tacked on as an afterthought. Most API’s have some form of documentation listing where the request and response fields are outlined. This is a good start but then they don’t list when the possible return types are and any corner cases where you can’t request certain things with other things.

This is probably down to being short of resources or knowhow when constructing a fairly simple, possibly low use API, but almost ensures that anyone who wants to implement it properly will be contacting them for more details, occasionally the company themselves don’t know why their API is behaving in a certain way.

I have also noticed some using WSDL in a way that doesn’t really actually specify anything by leaving the return type open. I’m no real fan of SOAP but at least a proper WSDL can go a long way to figuring out how an API will behave.

I think a bit of extra time to fully document an API will save a developer/ support staff a heap of time down the track where other developers are able to implement their API without ever getting in contact. At very least though, when you get questions from developers the answers should also go into the docs so the same issues are covered in future.

Working as the founder of a startup can be very a very rewarding pursuit and lets you tackle some big interesting problems that you may not have had the chance to touch being employed. It also allows you a lot more freedom to experiment and hack up bits and pieces, this can be some of the most fun in programming, a new interactive feature or a new way to present data to the user.

With all that though comes the other side, occasionally there are long stretches where you are getting things perfect on the backend, especially in the case of something highly data driven. I my case for the past couple of weeks I have been attempting to reconcile the outputs of many different reporting systems on affiliate networks that only loosely follow the same reporting scheme. This isn’t a new thing as many of the networks are already part of our system, though whereas last time I was kind of just skimming through and making them good enough, I am now revisiting and thinking of all the possible corner cases users could possibly have. The quality of these networks data retrieval varies from full OAuth implementation, to nice API’s with API key, right down to scraping using a plaintext username and password. I have a feeling how the guys from Yodlee must have felt early on.

I seem to have a fairly good approach to this kind of thing, goal directed in getting it all done ASAP and not stopping to much to worry about how tedious and boring the work has become. I also try to move onto another part of the large stack of related tasks when I get stuck somewhere. One thing I want to ensure though is that I am as through as possible, I’m sure to others involved I end up posing crazy corner cases that may never eventuate for any of our users but I figure the more I can cover now the less I get floored with complaints at launch.

I guess what I’m wondering is how others approach the boring grind parts of a startup early on, where there is no one else around to shoulder the load and the founder has to sit down and work the whole thing out themselves. We read plenty about the launches and the cool hacks, but how do you deal with having to go through large amounts of relatively boring activity of days on end to iron out edge cases and complex interactions between systems?