00:00:12.480
Welcome! Thank you for coming. I hope everybody enjoyed DHH's keynote and is ready to build monolithic web applications.
00:00:18.880
Today, we're going to talk about API design, specifically focusing on the people who actually have to write code against these APIs.
00:00:26.720
We will not be doing any coding at all today. Implementation is an implementation detail, so don't worry about that.
00:00:33.760
We're just going to focus on designing the API really well, and leaving the implementation to someone else.
00:00:52.480
My name is Pete Holiday, and I'm a lead engineer at Mailchimp. Mailchimp is an email service company, and we will tell you much more about it later.
00:01:04.879
I'm Kate Harlan, an engineering intern at Mailchimp and a Georgia Tech graduate next week. After graduation, I plan to work at Mailchimp full-time.
00:01:20.880
Version 2.0 of our API did many things well. About 250,000 users hit it every single day, and billions of requests come and go. It’s fairly popular. We conducted a survey not long ago and found that 75% of users thought it was good or excellent. Those are really promising numbers.
00:01:39.760
However, as we worked with it ourselves, we discovered some significant issues with the design and the challenges users were facing while trying to utilize the API. This talk is a reflection of that process of designing our newest version of the API, which is currently in beta.
00:01:55.439
It was originally supposed to be released a month ago, but software happens and it is late. This will be a fairly interactive session, so during several portions, I encourage you to chat with your neighbors. Please take a moment to introduce yourselves as you’re going to become good friends by the end of this.
00:02:40.800
I would like to know the gender ratio of the entire conference. I'm just curious! It seems to be fairly average, but still somewhat lacking in diversity. From my perspective, there appears to be about one woman for every eight attendees.
00:03:03.760
Okay, let's bring it back together. I think I’ve lost the room already. So, you all probably have at least a basic understanding of what an API is. It stands for Application Programming Interface.
00:03:10.720
APIs are ubiquitous in programming. If you’ve done any programming at all, you’ve used an API, as they serve as the interface between different software components. They allow two pieces of software to communicate across boundaries. For instance, Ruby blocks serve as boundaries for language features, class methods are APIs of that language, and object-oriented programming relies on classes that expose APIs. Today, we’ll specifically discuss web services, especially microservices.
00:04:02.640
The principles used to design a web service API are similar to the principles for designing any other API. One request I have is for the lights to be dimmed as it might help readers see the screen better. I guess it’s hard to read in the current lighting conditions.
00:05:09.680
While we work on that, let’s keep going. Developer-focused APIs reflect the movement we’ve seen over the past few years to enhance user experience within web applications. However, this focus has not yet mirrored API design, which remains somewhat chaotic in terms of appearance.
00:05:20.480
When we talk about developer-focused API design, we mean optimizing for the end user, not just the backend systems. Many APIs are designed for ease of implementation and maintenance, but they are not necessarily user-friendly.
00:05:40.960
When we center our focus on the end user, the person who will eventually use your API, it leads to great development experiences. So, what do developers want when using your API? Generally, developers want to get in, complete their task, and get out—ideally without touching your API again.
00:06:09.919
One major factor to consider here is that once developers write something using your API, you can’t change how it works without breaking their code. Therefore, you must version your APIs, ensuring that each version is robust and functional.
00:06:34.080
How many of you have experienced a frustrating API? Raise your hand if that's true. A few of you. Great! For 90 seconds, I would like you to discuss with your neighbors what made those bad experiences challenging.
00:08:08.000
I always carry a water bottle but have been losing it recently. It’s frustrating! Thanks for your understanding. Being a tech support person at events like these must be tedious.
00:09:27.120
This is where things start to get interesting as we transition into talking about developer frustrations with API design.
00:09:35.760
Let's raise our hands and discuss bad experiences with APIs without naming specific companies. It’s great to hear those stories. For instance, someone mentioned that the hotel industry relies heavily on poor XML standards. Others mentioned issues such as bad documentation and the complexity of having to make multiple API calls to achieve a single task.
00:10:31.760
What can we learn from these bad experiences? It's evident that easy tasks often seem more complicated, with too many endpoints and inadequate documentation.
00:10:44.479
Let’s try to understand what users ideally want to accomplish with an API. When using Mailchimp, for example, customers may want to send automatic emails upon certain triggers such as a new registration.
00:11:15.040
That brings us to our discussion on the specific features of an API, such as managing lists, sending campaigns, and tracking reports. To create an effective API, understanding user intent is crucial in order to design features that align with those needs.
00:11:49.199
Version 2.0 of the Mailchimp API was widely used, but during our discussions and reviews, we realized it had its faults. Moving forward with version 3.0, our mission is to prioritize developer experiences with a user-friendly design.
00:12:25.280
We expect to take a serious look at our user feedback and usage patterns to continually improve the API experience to ensure developers find root problems based on their API interactions.
00:12:42.800
There will be plenty of room for discussion of our findings where we will focus on aspects such as error rates and documentation quality to ensure clarity and accuracy.
