27
Reusable APIs Mike Amundsen @mamund @Layer7 @CAInc

Reusable APIs

Embed Size (px)

DESCRIPTION

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

Citation preview

Page 1: Reusable APIs

Reusable APIsMike Amundsen

@mamund@Layer7 @CAInc

Page 2: Reusable APIs

We need more reusable APIs

Too many "snowflake" APIsToo few generic descriptions of APIsToo often we code from "zero" every time

Page 3: Reusable APIs

We can do better

Page 4: Reusable APIs

Top 10 things we should STOP doing

Page 5: Reusable APIs

Stop mapping semantics to protocols

Page 6: Reusable APIs

Map semantics to messages instead.

Page 7: Reusable APIs

Stop hiding update & query rules in human-readable documentation

Page 8: Reusable APIs

Use inline hypermedia controls instead.

Page 9: Reusable APIs

Stop requiring devs to be protocol gurus

Page 10: Reusable APIs

Provide "accommodations" like SDKs when appropriate

Page 11: Reusable APIs

Stop making everyone use the same object model

Page 12: Reusable APIs

Share message models, not object models

Page 13: Reusable APIs

Stop describing services as single instances

Page 14: Reusable APIs

Describe services as abstract classes.

Page 15: Reusable APIs

Stop baking workflow into client code

Page 16: Reusable APIs

Put workflow in the message via hypermedia

Page 17: Reusable APIs

Stop breaking others people's code

Page 18: Reusable APIs

Take the "no breaking changes" pledge

Page 19: Reusable APIs

Take the "no breaking changes" pledge

Page 20: Reusable APIs

Stop making client devs re-code & re-deploy at random

Page 21: Reusable APIs

Use "dark release" to allow client devs to update on their own schedule

Page 22: Reusable APIs

Stop adding single points of failure

Page 23: Reusable APIs

Distribute not just storage, but also execution.

Page 24: Reusable APIs

Stop pretending the Web defies the laws of probability and physics

Page 25: Reusable APIs

We can do better10. Map semantics to messages

9. Use inline hypermedia

8. Provide SDKs when

appropriate

7. Share messages, not objects

6. Describe services as

abstract classes

5. Put workflow in messages

4. Take the "no breaking

changes" pledge

3. Use "dark release"

2. Distribute storage and

execution

1. Obey the laws of

probability and physics

Page 26: Reusable APIs

None of this is complicatedSome of it is hard.

Page 27: Reusable APIs

Let's talk aboutReusable APIs

Mike Amundsen@mamund

@Layer7 @CAIncg.mamund.com/top10stop