Future of Web Apps – Session 6 – Irresistible APIs – Kirsten Hunter
This is a live blog – don’t freak out if there are spelling mistakes.
Your API should be a first class product. It should not be a bolt on! You end up with a mess if that’s what you do!
You need to deliberately design your API for the things you want to do!
The people who use your API are not the same people as the back end engineers.
But why have an API? It shouldn’t be for monetisation unless it’s your only product! We will come back to this.
API first means that you build the API first and your main product even uses this API – again, not a bolt on!
Etsy went made the change to go API first, and are a big company. They had better communication and faster iterations.
They also used to generate feed for each user asynchronously every 15 minutes as it was heavy to run, but now with the API, performance is so quick that they changed it to be synchronous
If we have a product with a desktop and mobile model, this helps to build API first as you will never go back and implement in the API for mobile.
Netflix also benefitted from building an API first and this means that any new devices that come out can quickly be given support for Netflix.
Twitter uses Apis to drive usage. Again to encourage other people to use their API to build clients. They also got some ideas to implement from other people.
However, Twitter has done some bad practices when it comes to things like forcing API upgrades.
There are technical cases for APIs too. Telephony is hard. But twilios API allows us to add this functionality to our own apps within 5 minutes. Sendgrid do the same thing with email.
Also partner connectivity. Sometimes it came be hard to justify when you have an API. What is the business value. If you offer an API and a third party is using it, it’s great for you as a business as it’s more difficult for that customer of your API to switch to a competitor.
We can write user stories to determine where the API can add value. You should also add your own main product it uses your API.
If your user stories consider mobile, developers want to be lazy and call your API as few times as possible to get the job done and also don’t send too much data for performance.
You should consider if you would use your own API.
You could use expressive queries to get extended data about the thing you are querying. For example, you could optionally get related data to the entity you are requesting.
LinkedIn API lets users find out details about a user, but also a lot more meta data, such as did they go to the same school as me? And was it at the same time? Their API is very configurable
When you want API users to be able to query linked data, you can investigate hypermedia.
In the past we used xml, even now, developers that use compiled language might like to continue to use xml. Twitter annoyed users by dropping Json.
Make sure you use the right format (Json/xml) for your developers.
When considering authentication you shouldn’t need to worry about security of your web data. Just by having an API, this doesn’t mean that all of your data is suddenly available on the web. Using something like oauth allows you to control what’s going on.
If your API looks very similar to another API, It’s easier for users to implement
Design driven development is a bit like tdd. But using a schema and user stories. You should be thinking about your users/developers when you develop your API. Your developer experience is very important. Communicate with your developers and help them – they are your partners.
You should ask questions of your users, this is the only way you will get to find out where your API is lacking.
Value your developers!
Developers are not the same as regular people! Just making a pretty picture of your API is not going to work. Help them by creating examples and getting started guide. You have 5 minutes to do grab your user and convince them to use your API.
Support your users who write example code too, they will do some of your work for you. Don’t make assumptions about your users know and make sure you are sharing context with them
Try to let your developers do *something* before authenticating.
Also keep your users informed of what’s going on and provide decent support to them or they will go elsewhere. You can provide some help up front to help users help themselves.