A brilliant, undiscovered app developer just logged into the front page for your API program (please don’t tell me you just emailed a PDF), and made their first successful call. They’re frustrated, feeling like they don’t understand what just happened, and generally just exhausted.
Hopes of impressing colleagues with a quick demo espousing the ease of adoption have been dashed. They are eagerly digging through your content trying to find a way to explain the value of what your API brings to his company.
The biggest Nordic APIs conference to date was held in Stockholm, Sweden 18-19 September, 2013. As one of the organizers I am proud to say everything went very well and that we did what we set out to do – which was to create a place for the API community in the Nordics to meet in person.
During the conference there were a few themes that emerged – that APIs are about more than technology, that the security stack is maturing and that we have a strong API community.
Tictail, a Swedish e-commerce platform that manages over 24,000 stores spread across 110 different countries, launched their API on September 16, 2013. Because Tictail’s main focus is simplicity of use, they decided to offer developers the same tools they use internally to build this new platform. According to Carl Waldekranz, Tictail CEO, they ”want developers to have that same opportunity as [the company] continues to grow internationally.”
Back in 2006, Jeff Lindsayproposed a different way of consuming Web resources that would eliminate the need for constantly polling APIs for changes. This new pattern was called webhooks and has since been adopted by companies such as GitHub and Google.
The main advantage of the webhooks pattern is that your application doesn’t have to make periodic calls to APIs while it’s waiting for changes. Instead, APIs will call your application on a specific endpoint informing that something interesting has happened. What’s missing is a way to programmatically tell APIs that you’re interested in receiving calls and registering endpoints.
Globalizing APIs is hard. I’ve posted before about some of the pitfalls of dates and times in APIs in The 5 Laws of API Dates and Times, as well as content and currency localization in How to Localize Your API .
One area that I did not get into was how timezones can play a role when a specific time and location are in play.
Simply put: you cannot tell what the UTC offset of a given date+time will be, unless you know precisely where and when it will be. As such, this becomes the defining line for when we should supply timezones.