API Design Principles for Accelerated Development
Download as PPTX, PDF5 likes3,011 views
The document outlines key principles for accelerated API development, focusing on improving developer efficiency through techniques like lowering perceived latency and proper use of HTTP methods. It discusses trade-offs involved in API design, such as security versus usability and the benefits of automating interactions with HATEOAS. The overarching theme emphasizes that effective API architecture involves making informed decisions that best support developers' needs.
!["links": [
{
"href":"https://api.sandbox.paypal.com/v1/payments/
authorization/6H149011U8307001M",
"rel":"self",
"method":"GET"
},{
"href":"https://api.sandbox.paypal.com/v1/payments/
authorization/6H149011U8307001M/capture",
"rel":"capture",
"method":"POST"
},{
"href":"https://api.sandbox.paypal.com/v1/payments/
authorization/6H149011U8307001M/void",
"rel":"void",
"method":"POST"
}
]](https://image.slidesharecdn.com/2013junevelocityapidesignaccelerateddevelopment-130618104248-phpapp02/85/API-Design-Principles-for-Accelerated-Development-19-320.jpg)
API Design Principles for Accelerated Development
- 1. For Accelerated Development API Design Principles Jonathan LeBlanc Head of Developer Evangelism (North America) Github: http://github.com/jcleblanc Slides: http://slideshare.net/jcleblanc Twitter: @jcleblanc
- 2. The Exploration of API Design Blank Slate Constraints
- 3. Building APIs for Developers
- 5. Developer efficiency task 1 Lowering perceived latency for developers Lower Perceived Latency
- 6. What’s the Tradeoff? System Layering Result Caching
- 7. Layering the System Encapsulates legacy systems Simplified components Better load balancing abilities Systems can evolve independantly
- 9. Stateless System Latency Issues Data Duplication A + B A + C
- 10. Caching for Latency Reduction
- 11. Developer efficiency task 2 Use HTTP properly – standard request and response types Use HTTP Properly
- 13. Requests and Responses GET / PUT / POST / DELETE have specific actions Proper status codes and error responses
- 14. Don’t do This {"error": "error 10008"} Do This HTTP/1.1 400 Bad Request Content-Length: 35 {"message":"Problems parsing JSON"} Descriptive Messaging
- 15. Developer efficiency task 3 Building in automation – using HATEOAS Build in Automation
- 16. What’s the Tradeoff? Payload Size Code Length
- 17. How we Normally Consume APIs
- 18. Using HATEOAS to Automate
- 20. Developer efficiency task 2 Secure Data Resources
- 21. What’s the Tradeoff? Security Usability
- 22. Some Security Models Proprietary Solution Basic Authentication OAuth 1.0a OAuth 2 / OpenID Connect
- 23. Developer efficiency task 4 Offload complexity to the implementing provider Offload Complexity
- 24. The Complexities Authentication / Authorization Legacy API support Working between versioning API changes that break implementations Reduction in latency
- 25. API architecture is all about tradeoffs You are not making a perfect system, you are making a perfect system for your developers Bringing it all Together
- 27. http://bit.ly/api_design_for_devs Thank You! Jonathan LeBlanc Head of Developer Evangelism (North America) Github: http://github.com/jcleblanc Slides: http://slideshare.net/jcleblanc Twitter: @jcleblanc
Editor's Notes
- #4: At the end of the day, we need to be designing for the developers
- #5: API system standards vs. efficient developmentREST is all about the tradeoffs
- #6: Lowering perceived latency for developers
- #7: Reduction in system layeringCaching can reduce reliability (stale data)
- #8: Protects new systems from legacy APIs
- #9: Layering the system to separate legacy systems
- #12: Use HTTP properly – standard request and response types
- #16: Building in automation, using HATEOAS
- #17: Heavier payloads being sent throughReduction in developer code size & scalable architecture
- #21: Use HTTP properly – standard request and response types
- #24: Offload complexity to the implementing provider