6. HUMAN APIS
• Are built with applications– and especially their users– in mind
• Have some level of Developer Experience
• Could be leveraged by non-developers
• May be easily demonstrated in a web browser
• Have an orchestration layer to adapt to uses
7. HIERARCHY OF API NEEDS
Machine Experience
Developer Experience
Human Experience
Utility
8. HUMAN DOCUMENTATION
• Inspires
• Examines and Explains
• Meetings Developer Needs but has an entry point
for everyone
• Speaks to All Stakeholders
9. SOFTWARE FOR DEVELOPERS
Even when your business model is Developer-first
think of what their ultimate users and stakeholders
are going to be, and develop for that.
Engineers are smart.
They’ll find a way if the business (and humans) need
it.
10. APIS ARE FOR
HUMANS
Tyler Singletary
Klout Data, Lithium Technologies
Director of Platform
@harmophone
Editor's Notes
We all understand that APIs are consumed by applications
And that developers have to implement those APIs in those applications, whether they’re 1st party or 3rd party
I’m a bit of a hypocrite here, because I’ve advocated for machine-readable (and enforceable) terms of service– but these are meta-operations.
Nonetheless..
As we get further along into discussions about hypermedia APIs, API automation, it’s important to see where is composed amongst other needs.
We build bigger structures out of them, but sometimes we treat it like our only customer is that robot, and failing that, the developers.
When we think of them as built for machines, it has to have an effect on the overall design and application
This is why we focus on Developer Experience.
The reality is that we’ve got end users of those applications
They’re at home
They’re on the train
They’re at work, school.
They may not know about APIs now, but the public is starting to understand them, even if not by name.
Don’t ask “What can developers do with this?”
Ask: “What can end users do with this?”
I’m not saying Developer Experience isn’t important, but:
You have to have the base utility in the data, actions, and service you’re offering. If that’s not there, nothing else matters. A truly great Utility can even transcend all of these things– you might be able to get away with bad experience entirely.
Human Experience (User Experience?) is the closest to utility– if people can’t realize the value of an API in their lives and org, if its implementation somehow stagnates its utility, the rest doesn’t matter.
Developer Experience should come only after Huam Experience has been satisfied. Now we can focus on making the developer’s life easier, and this might mean tools, syntacical sugar, talk of payload formats, filters, sizing.
Lastly, while developers implement what becomes Machine Experience, only after we’ve satisified their needs can we build towards APIs that satisfy the requirements of an autonomous consumption or interaction.
This might mean having multiple APIs, or an orchestration layer on top of the APIs to satisfy all of these conditions.