Reusable APIs
Mike Amundsen
@mamund
@Layer7 @CAInc
We need more reusable APIs
Too many "snowflake" APIs
Too few generic descriptions of APIs
Too often we code from "zero" ev...
We can do better
Top 10 things we should
STOP
doing
Stop mapping semantics to protocols
Map semantics to messages instead.
Stop hiding update & query rules in
human-readable documentation
Use inline hypermedia controls instead.
Stop requiring devs to be protocol gurus
Provide "accommodations" like SDKs
when appropriate
Stop making everyone use the
same object model
Share message models,
not object models
Stop describing services as
single instances
Describe services as abstract classes.
Stop baking workflow into client code
Put workflow in the message
via hypermedia
Stop breaking others people's code
Take the "no breaking changes" pledge
Take the "no breaking changes" pledge
Stop making client devs re-code & redeploy at random
Use "dark release" to allow client devs
to update on their own schedule
Stop adding single points of failure
Distribute not just storage,
but also execution.
Stop pretending the Web defies the laws
of probability and physics
We can do better
10. Map semantics to messages

5. Put workflow in messages

9. Use inline hypermedia

4. Take the "no bre...
None of this is complicated
Some of it is hard.
Let's talk about

Reusable APIs
Mike Amundsen
@mamund
@Layer7 @CAInc
g.mamund.com/top10stop
Upcoming SlideShare
Loading in...5
×

Reusable APIs

12,828

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

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 g.mamund.com/top10stop
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×