Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Designing APIs

Designing APIs

When building a services architecture, the APIs between services may be the most important thing in the whole system. To ensure that you set your APIs right, think like a designer and start with the customer in mind.

Nic Benders

January 27, 2016
Tweet

More Decks by Nic Benders

Other Decks in Programming

Transcript

  1. ©2008-16 New Relic, Inc. All rights reserved. Designing APIs with

    Customers in Mind Nic Benders - Chief Architect, New Relic ©2008-16 New Relic, Inc. All rights reserved. 1
  2. ©2008-16 New Relic, Inc. All rights reserved. Safe Harbor This

    document and the information herein (including any information that may be incorporated by reference) is provided for informational purposes only and should not be construed as an offer, commitment, promise or obligation on behalf of New Relic, Inc. (“New Relic”) to sell securities or deliver any product, material, code, functionality, or other feature. Any information provided hereby is proprietary to New Relic and may not be replicated or disclosed without New Relic’s express written permission. Such information may contain forward-looking statements within the meaning of federal securities laws. Any statement that is not a historical fact or refers to expectations, projections, future plans, objectives, estimates, goals, or other characterizations of future events is a forward-looking statement. These forward-looking statements can often be identified as such because the context of the statement will include words such as “believes,” “anticipates,” “expects” or words of similar import. Actual results may differ materially from those expressed in these forward-looking statements, which speak only as of the date hereof, and are subject to change at any time without notice. Existing and prospective investors, customers and other third parties transacting business with New Relic are cautioned not to place undue reliance on this forward-looking information. The achievement or success of the matters covered by such forward-looking statements are based on New Relic’s current assumptions, expectations, and beliefs and are subject to substantial risks, uncertainties, assumptions, and changes in circumstances that may cause the actual results, performance, or achievements to differ materially from those expressed or implied in any forward-looking statement. Further information on factors that could affect such forward-looking statements is included in the filings we make with the SEC from time to time. Copies of these documents may be obtained by visiting New Relic’s Investor Relations website at ir.newrelic.com or the SEC’s website at www.sec.gov. New Relic assumes no obligation and does not intend to update these forward-looking statements, except as required by law. New Relic makes no warranties, expressed or implied, in this document or otherwise, with respect to the information provided 3
  3. ©2008-16 New Relic, Inc. All rights reserved. ▪ ▪ Where

    we started ©2008-16 New Relic, Inc. All rights reserved. 5
  4. ©2008-16 New Relic, Inc. All rights reserved. It wasn't great

    ©2008-16 New Relic, Inc. All rights reserved. Many teams in the same code Complex components Hidden dependencies Expensive to maintain 7
  5. ©2008-16 New Relic, Inc. All rights reserved. It was getting

    worse ©2008-16 New Relic, Inc. All rights reserved. Many teams in the same code Complex components Hidden dependencies Expensive to maintain Unpredictable behavior 8
  6. ©2008-16 New Relic, Inc. All rights reserved. What We Wanted

    Each component has a clear owner Smaller, easily understood components Explicit dependencies and interfaces Reduced maintenance cost Improved safety, graceful degradation 9
  7. ©2008-16 New Relic, Inc. All rights reserved. Organizations which design

    systems ... 
 are constrained to produce designs which are copies of the communication structures 
 of these organizations — Mel Conway 10
  8. ©2008-16 New Relic, Inc. All rights reserved. 16 ©2008-16 New

    Relic, Inc. All rights reserved. We were still in the monolith 16
  9. ©2008-16 New Relic, Inc. All rights reserved. Let's Take a

    Step ©2008-16 New Relic, Inc. All rights reserved. 17
  10. ©2008-16 New Relic, Inc. All rights reserved. Let's Take a

    Step Back ©2008-16 New Relic, Inc. All rights reserved. 18
  11. ©2008-16 New Relic, Inc. All rights reserved. When designing a

    system, you need to think like a designer ©2008-16 New Relic, Inc. All rights reserved. 19
  12. ©2008-16 New Relic, Inc. All rights reserved. Test your assumptions

    with real users How will they use the product to solve it? What problem is the user trying to solve? Remember: Design Affects Usage 20
  13. ©2008-16 New Relic, Inc. All rights reserved. ©2008-16 New Relic,

    Inc. All rights reserved. API Logic Data 23
  14. ©2008-16 New Relic, Inc. All rights reserved. building the service

    Design the API before ©2008-16 New Relic, Inc. All rights reserved. 24
  15. ©2008-16 New Relic, Inc. All rights reserved. ©2008-16 New Relic,

    Inc. All rights reserved. Write the Docs first Start with pseudocode Use a simple server to stub the API 25
  16. ©2008-16 New Relic, Inc. All rights reserved. What problem is

    the user trying to solve? How will they use the product to solve it? Test your assumptions with real users 26
  17. ©2008-16 New Relic, Inc. All rights reserved. Good artists copy,

    great artists steal. — Pablo Picasso ©2008-16 New Relic, Inc. All rights reserved. 27
  18. ©2008-16 New Relic, Inc. All rights reserved. Thanks! @nicbenders ©2008-16

    New Relic, Inc. All rights reserved. http://nicbenders.com/presentations/designing-apis/ 28