Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Reusable APIs


Published on

We need to create more reusable APIs, fewer "snowflakes" and better machine-readable APIs and descriptions. To this end, Mike Amundsen, Principal API Architect offers his "Top Ten things we need to STOP doing."

Published in: Technology, Education
  • Be the first to comment

Reusable APIs

  1. 1. Reusable APIs Mike Amundsen @mamund @Layer7 @CAInc
  2. 2. We need more reusable APIs Too many "snowflake" APIs Too few generic descriptions of APIs Too often we code from "zero" every time
  3. 3. We can do better
  4. 4. Top 10 things we should STOP doing
  5. 5. Stop mapping semantics to protocols
  6. 6. Map semantics to messages instead.
  7. 7. Stop hiding update & query rules in human-readable documentation
  8. 8. Use inline hypermedia controls instead.
  9. 9. Stop requiring devs to be protocol gurus
  10. 10. Provide "accommodations" like SDKs when appropriate
  11. 11. Stop making everyone use the same object model
  12. 12. Share message models, not object models
  13. 13. Stop describing services as single instances
  14. 14. Describe services as abstract classes.
  15. 15. Stop baking workflow into client code
  16. 16. Put workflow in the message via hypermedia
  17. 17. Stop breaking others people's code
  18. 18. Take the "no breaking changes" pledge
  19. 19. Take the "no breaking changes" pledge
  20. 20. Stop making client devs re-code & redeploy at random
  21. 21. Use "dark release" to allow client devs to update on their own schedule
  22. 22. Stop adding single points of failure
  23. 23. Distribute not just storage, but also execution.
  24. 24. Stop pretending the Web defies the laws of probability and physics
  25. 25. We can do better 10. Map semantics to messages 5. Put workflow in messages 9. Use inline hypermedia 4. Take the "no breaking changes" pledge 8. Provide SDKs when appropriate 7. Share messages, not objects 6. Describe services as abstract classes 3. Use "dark release" 2. Distribute storage and execution 1. Obey the laws of probability and physics
  26. 26. None of this is complicated Some of it is hard.
  27. 27. Let's talk about Reusable APIs Mike Amundsen @mamund @Layer7 @CAInc