API Design: It's Not Rocket Surgery (PHPUK13)

by Dave Ingram

Slide 1

Slide 1 text

API design It’s Not Rocket Surgery Dave Ingram @dmi PHP UK Conference 22nd February 2013

Slide 2

Slide 2 text

Who am I? • Senior operations engineer at DataSift • Was developer/RM at GroupSpaces for 41/2 years • Way too many projects • Involved in open source, including Phabricator • Occasionally found at London Hackspace • Twitter: @dmi • Github: dingram

Slide 3

Slide 3 text

Why am I giving this talk? • I’ve built a number of APIs • Both for GroupSpaces and my own projects • Sadly most are not public (yet!) • I’m also a consumer of many other APIs • Twitter • Foursquare • Tumblr • TfL • Spotify • . . . blah blah blah. . . • I’m opinionated

Slide 4

Slide 4 text

Feedback/thoughts via Twitter: #apirocketsurgery (or @dmi) http://joind.in/8 45

Slide 5

Slide 5 text

What this isn’t

Slide 6

Slide 6 text

T T REST REST REST REST REST REST REST EST EST ST ST ST T T REST REST REST REST REST REST REST REST REST REST REST REST REST REST R REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST R REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST REST R REST REST REST REST REST REST REST REST REST REST REST REST REST REST RES RES REST REST REST REST REST REST REST REST REST REST REST REST REST R R R RE RE RE RES RES REST R

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

There’s so much more!

Slide 10

Slide 10 text

URLs

Slide 11

Slide 11 text

URLs verbs

Slide 12

Slide 12 text

URLs verbs headers

Slide 13

Slide 13 text

URLs verbs headers authentication

Slide 14

Slide 14 text

URLs verbs headers authentication formats

Slide 15

Slide 15 text

URLs verbs headers authentication formats integrity

Slide 16

Slide 16 text

URLs verbs headers authentication formats integrity documentation

Slide 17

Slide 17 text

DOCUMENTATION

Slide 18

Slide 18 text

DOCUMENTATION (later)

Slide 19

Slide 19 text

Part 1: URLs

Slide 20

Slide 20 text

Make them versioned

Slide 21

Slide 21 text

Make them versioned, hackable

Slide 22

Slide 22 text

Make them versioned, hackable & meaningful

Slide 23

Slide 23 text

http://api.com/v1/

Slide 24

Slide 24 text

http://api.com/v1/users/

Slide 25

Slide 25 text

http://api.com/v1/users/31337

Slide 26

Slide 26 text

http://api.com/v1/users/31337/posts/

Slide 27

Slide 27 text

Look at URLs from a consumer perspective

Slide 28

Slide 28 text

They don’t care about internal implementation details

Slide 29

Slide 29 text

Use common sense

Slide 30

Slide 30 text

Don’t be afraid of the query string

Slide 31

Slide 31 text

Use query arguments to ﬁlter output or for (some) alternate representations

Slide 32

Slide 32 text

Good: searching & verbosity Bad: output format control (XML vs JSON)

Slide 33

Slide 33 text

Good: http://api.com/v1/search?q=foobar Bad: http://api.com/v1/search/foobar

Slide 34

Slide 34 text

Good: http://api.com/v1/foo.json Bad: http://api.com/v1/foo?format=json

Slide 35

Slide 35 text

Part 2: Verbs

Slide 36

Slide 36 text

• GET = get() • PUT = setAll() / new Obj($id) • POST = new Obj() / doStuff() / set() • DELETE = delete() • HEAD ≈ getMetadata() • OPTIONS ≈ reﬂection/permissions

Slide 37

Slide 37 text

Must at least handle GET/POST

Slide 38

Slide 38 text

Can emulate PUT/DELETE

Slide 39

Slide 39 text

For example: POST http://api.com/v1/foo/42!PUT POST http://api.com/v1/foo/11!DELETE

Slide 40

Slide 40 text

Remember that POST can have side-effects and is never cached

Slide 41

Slide 41 text

PUT and DELETE are idempotent, which means they have the same effect even if they’re repeated

Slide 42

Slide 42 text

HEAD is rare and can probably be ignored

Slide 43

Slide 43 text

OPTIONS is used by CORS, but otherwise rare

Slide 44

Slide 44 text

CORS?

Slide 45

Slide 45 text

Cross-Origin Resource Sharing

Slide 46

Slide 46 text

A way to allow in-browser cross-origin XMLHTTPRequests Support: FF3.5+, Chrome 4+, Safari 4+, Opera 12+, IE8+ (partial), IE10+ (full), iOS 3.2+, Android 2.1+ http://www.w3.org/TR/cors/ http://caniuse.com/cors

Slide 47

Slide 47 text

Origin & Allow-Origin A way to allow in-browser cross-origin XMLHTTPRequests Support: FF3.5+, Chrome 4+, Safari 4+, Opera 12+, IE8+ (partial), IE10+ (full), iOS 3.2+, Android 2.1+ http://www.w3.org/TR/cors/ http://caniuse.com/cors

Slide 48

Slide 48 text

Part 3: Headers

Slide 49

Slide 49 text

Headers are important too! (and you can be clever)

Slide 50

Slide 50 text

Accept The MIME types the client will accept. No need to use ﬁle extensions to decide what content type to serve!* Accept-Language The languages the client will accept. No need to ask clients or (worse) just assume English responses.

Slide 51

Slide 51 text

Some headers reduce trafﬁc (important for mobile)

Slide 52

Slide 52 text

• ETag – A unique tag for the content • If-(None-)Match – Check ETag • If-(Un)Modified-Since – Is it newer? • Cache-Control – Can it be cached? • Expires – How long is it valid? • Vary – Additional caching rules

Slide 53

Slide 53 text

Beware: some proxies may not pass custom headers

Slide 54

Slide 54 text

Beware: even some standard headers are not safe

Slide 55

Slide 55 text

Prefer headers, but accept other methods

Slide 56

Slide 56 text

Part 4: Authentication & Authorization

Slide 57

Slide 57 text

OAuth2 over HTTPS

Slide 58

Slide 58 text

Much simpler than OAuth1 (and similar to session cookies)

Slide 59

Slide 59 text

Many libraries for OAuth2 for many platforms as it’s a popular standard

Slide 60

Slide 60 text

For extra security use OAuth2-MAC

Slide 61

Slide 61 text

OAuth2-MAC uses signatures instead of bearer tokens, so secrets stay secret

Slide 62

Slide 62 text

Then again, the author of OAuth2 has now advised not upgrading from OAuth 1.0a and either using OAuth 1.0a for new sites or staying close to a large provider’s implementation

Slide 63

Slide 63 text

No need to worry about rate-limiting (to start with*) 3scale, Apiaxle, Mashery can help

Slide 64

Slide 64 text

Part 5: Formats

Slide 65

Slide 65 text

Sane default: JSON, plus envelope with metadata

Slide 66

Slide 66 text

{ "meta": { "code": 2 , "dev_notes ": [ "This endpoint is deprecated" ] }, "response ": { ... } }

Slide 67

Slide 67 text

Metadata envelope helps with JSONP and limited clients that discard errors

Slide 68

Slide 68 text

Having metadata allows out-of-band information, like deprecation warnings

Slide 69

Slide 69 text

What about XML?

Slide 70

Slide 70 text

*Hypertext as the Engine of Application State HATEOAS* is a nice idea, although it’s very verbose (but useful for building an API explorer)

Slide 71

Slide 71 text

HATEOAS adds links to related endpoints in the response

Slide 72

Slide 72 text

Don’t forget: mobile bandwidth is still very limited

Slide 73

Slide 73 text

Timestamps • ISO-8601 2 12- 5- 3T19: : Z Human-readable, but needs parsing • UTC seconds since epoch: 1336 716 Easily machine-usable

Slide 74

Slide 74 text

Should your API really be human-readable? It’s better to help your consumers.

Slide 75

Slide 75 text

Part 6: Data integrity

Slide 76

Slide 76 text

Allow your consumers to cache data whenever possible

Slide 77

Slide 77 text

Encourage use of request headers: • GET: • If-Modified-Since • If-None-Match • POST/PUT/DELETE: • If-Unmodified-Since • If-Match

Slide 78

Slide 78 text

Return useful response headers: • Last-Modified • Expires • ETag • Cache-Control

Slide 79

Slide 79 text

Deal with preconditions and give correct response codes

Slide 80

Slide 80 text

Useful status codes: 4 5 Method Not Allowed 4 6 Not Acceptable 412 Precondition Failed 428 Precondition Required* 429 Too Many Requests* *New in RFC6585

Slide 81

Slide 81 text

For example: ETag and Last-Modified can help prevent race conditions

Slide 82

Slide 82 text

PUT /v1/wiki/dealing -with -conflicts HTTP /1.1 Host: api.com Content -Type: text/html ... 428 Precondition Required ETag: "x-rev -11294" Last -Modified: Sat , 18 Feb 2 12 11: 9:21 GMT ...

Slide 83

Slide 83 text

PUT /v1/wiki/dealing -with -conflicts HTTP /1.1 Host: api.com Content -Type: text/html ... 428 Precondition Required ETag: "x-rev -11294" Last -Modified: Sat , 18 Feb 2 12 11: 9:21 GMT ...

Slide 84

Slide 84 text

PUT /v1/wiki/dealing -with -conflicts HTTP /1.1 Host: api.com Content -Type: text/html ... 428 Precondition Required ETag: "x-rev -11294" Last -Modified: Sat , 18 Feb 2 12 11: 9:21 GMT ...

Slide 85

Slide 85 text

PUT /v1/wiki/dealing -with -conflicts HTTP /1.1 Host: api.com Content -Type: text/html ... 428 Precondition Required ETag: "x-rev -11294" Last -Modified: Sat , 18 Feb 2 12 11: 9:21 GMT ...

Slide 86

Slide 86 text

PUT /v1/wiki/dealing -with -conflicts HTTP /1.1 Host: api.com If -Unmodified -Since: Sat , 18 Feb 2 12 11: 9:21 GMT If -Match: "x-rev -11294" Content -Type: text/html ... 412 Precondition Failed ETag: "x-rev -11467" Last -Modified: Sat , 25 Feb 2 12 14:42:53 GMT ...

Slide 87

Slide 87 text

Slide 88

Slide 88 text

Slide 89

Slide 89 text

Slide 90

Slide 90 text

Part 7: Documentation

Slide 91

Slide 91 text

Documentation is important

Slide 92

Slide 92 text

If people can’t understand your API, they won’t use it

Slide 93

Slide 93 text

Use examples liberally. . . and make sure they’re both up-to-date and correct!

Slide 94

Slide 94 text

Consider linking your examples to your automated tests (You do have them, right?)

Slide 95

Slide 95 text

Assume nothing; explain everything (What is an ID? string[8]? int32? uint64?)

Slide 96

Slide 96 text

Be helpful: provide an interactive console e.g. Apiary, Apigee console, Mashery’s iodocs

Slide 97

Slide 97 text

And ﬁnally: Statistics

Slide 98

Slide 98 text

Record numbers for anything and everything you can imagine

Slide 99

Slide 99 text

Everybody loves graphs (and they’re important for understanding API usage and performance)

Slide 100

Slide 100 text

Things to measure Counters: HTTP status (200, 400, 500, . . . ) Tokens issued Token refreshes Clients created Client usage Auth successes Auth failures Auth grants Auth rejections DB queries API version/release Client type . . . Avg response time: Auth requests General requests Speciﬁc subsystems . . . Other Memory usage Client location . . .

Slide 101

Slide 101 text

Thanks! Any questions? Feedback via joind.in: http://joind.in/8 45 or #apirocketsurgery or @dmi Slides: http://www.dmi.me.uk/talks/ Built in L ATEX Inspired by: http://goo.gl/ mT55