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 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

4. The Tradeoff Decision

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

8. Separation of Concerns

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

12. What’s the Tradeoff?

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

19. "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"
}
]

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