Your SlideShare is downloading. ×
API design principles for accelerated development
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

API design principles for accelerated development


Published on

Audio from this presentation is available at …

Audio from this presentation is available at

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

Published in: Technology, Business

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • At the end of the day, we need to be designing for the developers
  • API system standards vs. efficient developmentREST is all about the tradeoffs
  • Lowering perceived latency for developers
  • Reduction in system layeringCaching can reduce reliability (stale data)
  • Protects new systems from legacy APIs
  • Layering the system to separate legacy systems
  • Use HTTP properly – standard request and response types
  • curl -i -H "Accept: application/json" -H "X-HTTP-Method-Override: DELETE" -X POST
  • Heavier payloads being sent throughReduction in developer code size & scalable architecture
  • A lot of debate on whether versioning should go in the headers or URL
  • Use HTTP properly – standard request and response types
  • JSONP can cause XSS issues where the external site is compromised, CORS allows websites to manually parse responses to ensure security
  • Offload complexity to the implementing provider
  • Nouns are good, verbs are bad
  • Transcript

    • 1. API Design Principles For Accelerated Development Jonathan LeBlanc (@jcleblanc) Head of Developer Evangelism PayPal North America
    • 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 independently
    • 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 Not Hindering with HTTP
    • 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. X-Rate-Limit-Limit Number of requests allowed in current period X-Rate-Limit-Remaining Number of remaining requests in current period X-Rate-Limit-Reset Number of seconds left in current period Useful Responses on Rate Limiting
    • 16. Use Status Cats! Don’t Want to Use Boring Responses?
    • 17. Allowing HTTP Overriding curl -i -X POST -H "Content-Type:application/json" -H "X-HTTP-Method-Override: PUT" Injecting PUT / DELETE methods when HTTP client only supports GET / POST
    • 18. Action Automation
    • 19. What’s the Tradeoff? Payload Size Code Length
    • 20. RESTful API Core Concepts Honor HTTP request verbs Use proper HTTP status codes No version numbering in URIs Return format via HTTP Accept header Double Rainbow: Discovery via HATEOAS
    • 21. To Version or Not to Version
    • 22. Uniform Interface Sub-Constraints Resource Identification Resources must be manipulated via representations Self descriptive messages Hypermedia as the engine of application state
    • 23. How we Normally Consume APIs
    • 24. Using HATEOAS to Automate
    • 25. How HATEOAS Works curl -v -X GET ation/2DC87612EK520411B -H "Content-Type:application/json" -H "Authorization:Bearer ENxom5Fof1KqAffEsXtx1HTEK__KVdIsaCYF8C" You make an API request
    • 26. "links": [ { "href":" authorization/6H149011U8307001M", "rel":"self", "method":"GET" },{ "href":" authorization/6H149011U8307001M/capture", "rel":"capture", "method":"POST" },{ "href":" authorization/6H149011U8307001M/void", "rel":"void", "method":"POST" } ]
    • 27. Developer efficiency task 2 Secure Data Resources
    • 28. What’s the Tradeoff? Security Usability
    • 29. Some Security Models Proprietary Solution Basic Authentication OAuth 1.0a OAuth 2 / OpenID Connect Cross-Origin Resource Sharing (CORS)
    • 30. A Modern Approach CORS Client-side SDK OpenID Connect Server-side SDKs
    • 31. Working on the Server Side SDKs Secure Token Management Simplified Development
    • 32. Cross Origin Issues and Options Access to other domains / subdomains is restricted (same origin policy) JSONP to request resources across domains Only supports HTTP GET requests Cross-origin resource sharing (CORS) Supports additional range of HTTP requests
    • 33. Can you use it?
    • 34. How Does it Work? OPTIONS /v1/oauth2/token HTTP/1.1 Origin: Access-Control-Request-Method: PUT Host: Accept-Language: en-US Connection: keep-alive ... Site sends Origin header to server
    • 35. How Does it Work? Server responds with matching Access-Control-Allow-Origin header Access-Control-Allow-Origin: Access-Control-Allow-Methods: GET, POST, PUT Content-Type: text/html; charset=utf-8
    • 36. Developer efficiency task 4 Offload complexity to the implementing provider Offload Complexity
    • 37. The Complexities Authentication / Authorization Legacy API support Working between versioning API changes that break implementations Reduction in latency
    • 38. GET /payment POST /sale POST /payment DELETE /refund GET /getSinglePayment POST /setNewSingleSale POST /addNewSinglePayment DELETE /issueSingleRefund URL Structure, Verbs, and Nouns
    • 39. Representations on Update / Create { "id": "PAY-17S8410768582940NKEE66EQ", "create_time": "2013-01-31T04:12:02Z", "update_time": "2013-01-31T04:12:04Z", "state": "approved", "intent": "sale", "payer": {...}, "transactions": [{...}], "links": [{...}] } Send enough detail to not have to make another request to the API
    • 40. 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
    • 41. Thanks! Questions? Jonathan LeBlanc (@jcleblanc) Head of Developer Evangelism PayPal North America