Reusable APIs
 

Reusable APIs

on

  • 7,299 views

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."

Statistics

Views

Total Views
7,299
Slideshare-icon Views on SlideShare
2,729
Embed Views
4,570

Actions

Likes
13
Downloads
26
Comments
0

14 Embeds 4,570

http://daumdna.tistory.com 2951
http://d.hatena.ne.jp 1498
http://feedly.com 46
http://www.hanrss.com 25
https://twitter.com 21
http://plus.url.google.com 10
http://getpocket.com 5
http://www.inoreader.com 4
http://222.112.8.34 3
http://translate.googleusercontent.com 2
http://www.feedspot.com 2
http://mail.itxsecurity.com 1
https://www.rebelmouse.com 1
http://rss.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Reusable APIs Reusable APIs Presentation Transcript

    • 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" every time
    • 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 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
    • 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