Recommended
Recommended
More Related Content
What's hot
Viewers also liked
Viewers also liked (9)
Similar to APIs are for humans (defrag-con)
Similar to APIs are for humans (defrag-con) (20)
Recently uploaded
Recently uploaded (20)
APIs are for humans (defrag-con)
- 1. APIS ARE FOR HUMANS Tyler Singletary Klout Data, Lithium Technologies Director of Platform @harmophone
- 2. A trend towards APIs for machines
- 3. Complex human endeavors built on APIs.
- 4. Developers are human But often come with pro-robot bias
- 5. APIs are for humans
- 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.