Michael Hibay is an API evangelist, architect and CTO at Vesti. He helps organizations to establish, evolve and mature their API strategies.
- What’s the difference between an API catalogue and an affordance catalogue?
- What are affordances and how do they define the usability of a system?
- Why are affordances similar to languages?
The interview got split into 2 episodes. In this first episode, Michael argued that versionless APIs built through an affordance approach, introduce new capabilities without causing breaking changes. An affordance approach in API design also saves money by avoiding the need for new iterations and API versions.
The host is Kristof Van Tomme.
03:02 overcompetition: there is a destructive level of competition. Friendly rivalry vs. the “elimination” of competitors
04:40: profit over everything: a short term strategy
05:45 monocultural companies/economies are not only boring but dangerous as well
06:30 tension between qulitative and quantitative: you can’t really quantify the “resilience level” of a system
8:00 affordance catalogs vs. API catalogs
9:20 APIs and affordances
10:00 affordances: potential for capabilities
12:10 data doesn’t give us affordance on its own. We have to mine it
12:30 “affordance is an immediate understanding of being able to do something without work”
12:50 affordances define how usable a system is
14:10 the API is the core of you user experience
15:20 we create complex machines and forget how the building blocks came together
16:00 we don’t have to spend conscious time on creating affordances (we understand gravity intuitively, we know how it works, it is an “affordance”, but we don’t think about it in everyday life)
17:35 affordances mean creating this kind of knowledge and interconnection with digital systems
17:50 an affordance catalog is more than publishing affordances: it is also about changing culture, education, etc.
18:10 it is a socio-technical solution. An API catalog is only a technical solution.
21:40 defining an affordance catalog is a constant effort, it like a language
23:50 API design first in theory assumes that you know in advance what you want. But affordances are evolving
26:30 service vs product - products should be affordances?
31:58 Language metaphor. “standards” and data centric approach: you have to cover all the use cases and audiences. It is impossible. The “affordance” approach is dynamic and counts with negotiable elements.
34:00 language is also changing but the context makes it clear what one means.
34:20 self-descriptive messages
35:30 API governance: in a lot of ways managing change is very similar to affordances. First step: identifying and defining different perspectives in a system.
39:30 when you have a versionless API that is truly driven by affordances: it is decoupled from the operational API, and the process of adding new affordances is not breaking anything