#GlueCon 2014 Notes: API First: Designing your Product from the Platform Out – Kirsten Hunter, 3Scale
API First: Designing your Product from the Platform Out – Kirsten Hunter, 3Scale APIs are often an afterthought for developers You will always have another client Taking an API first approach is the next level of MVC and allows for quick iterations “I can’t do that. It’s Hard” “We’ll never have a mobile client” Examples LOB – Cloud printing and mailing service. API as a product. Everything internal and external uses REST APIs Instagram – They were mobile first, but became API-focused due to heavy need for code reuse between web and mobile platforms 3Scale – API management company Etsy – Made $1B last year. They moved to API-first over the course of a year after dealing with lagging APIs and duplicate code Results of going API First Encourages communication between backend and mobile developers Testing around APIs will be great if everyone is using it (and depending on it) How to get developers to move from an old version to a new version of an API? You can’t sunset an API version. So, create goodies and incentives to encourage them to move to the new version (capabilities, better examples) Should you consider SDK first? No, developers should use the API and understand it (and HTTP/REST), not hide it in an SDK that makes it harder to debug Take the time to go API First now, to save time in the future regarding bugs and duplication of code Anytime you do something that developers don’t like, they go away. This is usually about inconsistency between APIs When starting from use cases, you have less organic API growth and therefore lack of constant change vs. the “we need an API, make one for our mobile developers” Backend engineers are most concerned about stability (it does what it is supposed to do), not about usability (what you want to do) API design is definitely an “area of expertise” – not everyone has it. It’s important to get input from those who actually use it Developers aren’t “lucky” to use your API. They are your partners – honor them by respecting their time by building a great developer experience
API First: Designing your Product from the Platform Out – Kirsten Hunter, 3Scale
- APIs are often an afterthought for developers
- You will always have another client
- Taking an API first approach is the next level of MVC and allows for quick iterations
- “I can’t do that. It’s Hard”
- “We’ll never have a mobile client”
- Examples
- LOB – Cloud printing and mailing service. API as a product. Everything internal and external uses REST APIs
- Instagram – They were mobile first, but became API-focused due to heavy need for code reuse between web and mobile platforms
- 3Scale – API management company
- Etsy – Made $1B last year. They moved to API-first over the course of a year after dealing with lagging APIs and duplicate code
- Results of going API First
- Encourages communication between backend and mobile developers
- Testing around APIs will be great if everyone is using it (and depending on it)
- How to get developers to move from an old version to a new version of an API? You can’t sunset an API version. So, create goodies and incentives to encourage them to move to the new version (capabilities, better examples)
- Should you consider SDK first? No, developers should use the API and understand it (and HTTP/REST), not hide it in an SDK that makes it harder to debug
- Take the time to go API First now, to save time in the future regarding bugs and duplication of code
- Anytime you do something that developers don’t like, they go away. This is usually about inconsistency between APIs
- When starting from use cases, you have less organic API growth and therefore lack of constant change vs. the “we need an API, make one for our mobile developers”
- Backend engineers are most concerned about stability (it does what it is supposed to do), not about usability (what you want to do)
- API design is definitely an “area of expertise” – not everyone has it. It’s important to get input from those who actually use it
- Developers aren’t “lucky” to use your API. They are your partners – honor them by respecting their time by building a great developer experience