Your SlideShare is downloading. ×
0
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
Reusable APIs
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

Reusable APIs

12,041

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 …

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
0 Comments
16 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
12,041
On Slideshare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
37
Comments
0
Likes
16
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×