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.
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.