Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
RailsConf 2018: Broken APIs Break Trust: Tips for Creating and Updating APIs by Alex Wood For many of us, APIs and their client libraries are the face of our applications to the world. We need to innovate with new features, but breaking changes are toxic to customer trust. In this session you will pick-up concrete design patterns that you can use and anti-patterns that you can recognize so that your service API or library can continue to grow without breaking the world. Using real APIs and open source libraries as a case study, we’ll look at actual examples of specific strategies that you can employ to keep your API backwards compatible without painting yourself into a corner.
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In this session from RailsConf 2018, Alex Wood explores the critical theme of API design, particularly focusing on how broken APIs can damage customer trust. The presentation emphasizes the importance of maintaining backwards compatibility when designing APIs and client libraries. Key points discussed include: - **Understanding API Changes**: Alex outlines what breaking changes are and highlights the significance of avoiding them to maintain user trust and avoid unintended consequences. - **Common Language**: Establishing a common terminology is essential for discussing API design effectively. Terms like resources, shapes, and operations help define the parts of an API clearly. - **Client Lifecycle**: The interaction between a client and an API is detailed through examples, emphasizing the necessity for older clients to remain functional even as new features are added. - **Design Principles**: Strategies for ensuring backwards compatibility are discussed, such as adding new optional parameters instead of changing existing ones, and the potential pitfalls of changing data types or required parameters. - **Safe vs Unsafe Changes**: Alex illustrates safe modifications—like adding optional fields—versus unsafe ones, such as removing or renaming existing fields that could lead to client breakage. - **Empathy and User Experience**: A core message revolves around understanding the user experience; changes should not disrupt existing workflows unnecessarily. - **Constraints and Validation**: Modifications to constraints must be handled delicately to avoid breaking existing client implementations. - **Future Proofing**: Encouraging developers to design with future compatibility in mind, considering how new states or exceptions might affect clients across various programming languages. - **Conclusion and Recommendations**: In the final segment, Alex shares specific do’s and don’ts of API design, recommending that developers focus on discoverability and usability while avoiding practices like removing or renaming existing API members. This session is an insightful guide for developers aiming to improve API reliability and user satisfaction.
Suggest modifications
Cancel
