api design principles for accelerated development
DESCRIPTION
One of the largest issues in API architecture development is that the task is often driven by the pragmatic indoctrination of a specification into a product rather than designing around the speed and ease of development, usually due to a separation between the engineering teams and their core developer user base. Extending upon the ideas of API design around developer accelerated development delivered in the PayPal keynote, we will take a deeper look into some of the great techniques delivered to us through the RESTful specification, applying them to developer API consumption practices with the intention of creating efficient best practices for rapid development. Within this talk we will explore what we have learned through reconstructing our API backbone at PayPal for our developer community, including: - API automation practices for code reduction and application longevity - Open security standards that promote developer integration ease and maintain strict security practices - RESTful API architecture best practices for developer centric accelerated developmentTRANSCRIPT
For Accelerated Development
API Design Principles
Jonathan LeBlancHead of Developer Evangelism (North
America)Github: http://github.com/jcleblanc
Slides: http://slideshare.net/jcleblancTwitter: @jcleblanc
The Exploration of API Design
Blank Slate Constraints
Building APIs for Developers
The Tradeoff Decision
Developer efficiency task 1
Lowering perceived latency for developers
Lower Perceived Latency
What’s the Tradeoff?
System Layering
Result Caching
Layering the System
Encapsulates legacy systems
Simplified components
Better load balancing abilities
Systems can evolve independantly
Separation of Concerns
Stateless System Latency Issues
Data Duplication
A + B
A + C
Caching for Latency Reduction
Developer efficiency task 2
Use HTTP properly – standard request and response types
Use HTTP Properly
What’s the Tradeoff?
Requests and Responses
GET / PUT / POST / DELETE have specific actions
Proper status codes and error responses
Don’t do This{"error": "error 10008"}
Do ThisHTTP/1.1 400 Bad RequestContent-Length: 35
{"message":"Problems parsing JSON"}
Descriptive Messaging
Developer efficiency task 3
Building in automation – using HATEOAS
Build in Automation
What’s the Tradeoff?
Payload Size Code Length
How we Normally Consume APIs
Using HATEOAS to Automate
"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" }]
Developer efficiency task 2Secure Data Resources
What’s the Tradeoff?
Security Usability
Some Security Models
Proprietary Solution
Basic Authentication
OAuth 1.0a
OAuth 2 / OpenID Connect
Developer efficiency task 4
Offload complexity to the implementing provider
Offload Complexity
The Complexities
Authentication / Authorization
Legacy API support
Working between versioning
API changes that break implementations
Reduction in latency
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
http://bit.ly/api_design_for_devs
Thank You!
Jonathan LeBlancHead of Developer Evangelism (North
America)Github: http://github.com/jcleblanc
Slides: http://slideshare.net/jcleblancTwitter: @jcleblanc