LF_APIStrat17_The Great API Redesign
1 like102 views
The document outlines the API redesign process for DNSimple, including the introduction of versioning and a dedicated hostname for API requests. It discusses the reasons for adopting a separate hostname and path-based versioning, and provides a roadmap for future enhancements. Key milestones and metrics are presented, highlighting team collaboration and the development of multiple API clients.
LF_APIStrat17_The Great API Redesign
- 1. The Great API Redesign Simone Carle,, DNSimple
- 5. "This PR is a first step towards API versioning and using a dedicated hostname for API."
- 6. "This PR is a first step towards API versioning and using a dedicated hostname for API." Dec 28, 2013
- 7. Dec 28, 2013 v0 API v0
- 8. API v0 • Same hostname as website • No versioning • No metrics • Shared Rails controllers
- 9. It worked ™ 😬
- 11. Jan 14, 2014Dec 28, 2013 v0 v1 API v1
- 12. API v1 • Introduce hostname api.dnsimple.com • Introduce path-based versioning • SGll uses the same Rails controllers • Simple transiGon through minimal changes
- 14. Why a separate hostname? • Easily flag requests as API requests • Improved error handling due to clear indicaGon of what is an API call • Adds the ability to extract API code from controllers • Provides easier scaling
- 15. Why path-based versioning? The approach I followed is simple. May be not the most restful, but it's the one very commonly adopted that will also allow us to switch to a mime-based approach (in case we want to follow that route in the future).
- 16. Why path-based versioning? • API version is embedded in the path and it prefixes the URL • Everything in the URL is easily visible in logs • Easiest implementaGon for both producGon and consumpGon • Hi,ng path-based versioned APIs with a browser is easy • New versions increase the major number • Path and verb changes can be introduced at major version
- 17. Jan 14, 2014Dec 28, 2013 v0 v1 API v1
- 18. Jan 14, 2014Dec 28, 2013 v0 v1 v2 API v2
- 19. Separate ApplicaDon • Use of a separate (sub)applicaGon • No longer Gghtly coupled to the Rails controllers hWp://hanamirb.org hWp://confreaks.tv/videos/railsconf2016-developing-and-maintaining-a-plaorm-with-rails-and-lotus
- 20. the Roadmap • MulG-account • Reusable shared business logic • Response serializaGon • PaginaGon, SorGng and Filtering • AuthenGcaGon • Rate limiGng • Webhooks • API clients
- 23. May 2, 2016 API clients Java PHP May 2, 2016 Sep 6, 2016 Sep 13, 2016 hWps://slidr.io/weppos/using-go-to-guide-api-design-decisions-dotgo-2016
- 24. API clients • Developing clients gets easier with each new client • Common design paWerns emerge • Shared HTTP fixtures • We built a foundaGon for API clients development hWps://blog.dnsimple.com/2017/01/api-client-tesGng-with-hWp-fixtures/
- 25. PrioriDes • Gathered metrics on v1 endpoint usage • PrioriGzed implementaGon based on usage
- 26. Jan 14, 2014 Mar 9, 2016 (Beta) Dec 13, 2016 (GA) Dec 28, 2013 v0 v1 v2 API v2
- 27. Stats • 717 Days from "Start" to "Finish" • 3 (almost) full-Gme team members out of 11 total, with a collaboraGve effort from the enGre DNSimple team • 4 official API clients, with 2 more under development • 75 API methods currently available (*) • 251 Dckets across 7 major milestones • ~423 API related support Dckets handled in the last year • ~1934 commits across the 4 API clients and applicaGon
- 28. What's next? • Facilitate transiGon to API v2 • Implement new methods (e.g. cerGficate, pricing) • Adopt a formal language to describe the API
- 30. Lessons • Simple transiGon through minimal changes • Be a producer and a consumer • Provide official clients (and/or contribute) • Measure decisions • Invest into the API