Designing an API For Developer Happiness

Building an API the Cronofy way

Recently, we sponsored and attended Speedhack, a three hour hacking event at the fantastic API Days/API Strat conference in Berlin.

As part of this event, I also gave a talk about some of the decisions we made when designing and building the Cronofy Calendar API. As Cronofy was created by developers, we had a good idea from the start of what we wanted to see, how we wanted it to work, and what we thought would be most useful for other developers using it – regardless of context, language, or working environment.

However, as with anything development-related, it wasn’t that simple in practice (if it were, it would have been done a long time ago!).

API design and delivery is so fraught with ‘no turning back’ decisions that it’s something we sweated long and hard over. As an example, one of the key decisions that we’re most pleased about is that we handle ID mapping on behalf of our clients. When you push an event through our API you give us the ID and we respect that as your identifier for all subsequent transactions. This also makes our API super responsive as we’re not generating yet another arbitrary mapping link in the chain as a blocking operation.

Designing an API for developer happiness

If you're interested in finding out more about our API design decisions, I've uploaded the slides and video of my talk about designing an API. It covers decisions and ideas relating to:

• On-boarding
• Documenting
• Confidence in decision making
• Using existing API patterns for user familiarity
• Fixing and logging
• Confronting unhappy paths
• Educating and training customers
• Working towards eventual consistency

...plus a lot more.View the slidedeck below:

‍

‍

As always, if you have any feedback or suggestions, please get in touch: @cronofy on Twitter or hello@cronofy.com.