Developer Experience is important, and that includes much more than the technical design of an API. It also includes the documentation and support as well as the pricing and the legal licensing terms. In almost every API project I have been involved in the legal details have been slapped on last-minute, usually by a lawyer that does not know anything about APIs or technology.
There are also way too many examples of API licensing terms that are actively developer hostile, which does not really invite developers to use the API (assuming they read the terms of service that is).
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.
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.