api design and more (friday training at itnig)

55
API design and more

Upload: itnig

Post on 08-May-2015

626 views

Category:

Technology


0 download

DESCRIPTION

Friday Training by Jordi Romero about the challenges of creating an API for Teambox

TRANSCRIPT

Page 1: Api Design and More (Friday Training at Itnig)

APIdesign and more

Page 2: Api Design and More (Friday Training at Itnig)
Page 4: Api Design and More (Friday Training at Itnig)
Page 5: Api Design and More (Friday Training at Itnig)

API

Page 6: Api Design and More (Friday Training at Itnig)

Application Programming Interface

Page 7: Api Design and More (Friday Training at Itnig)
Page 8: Api Design and More (Friday Training at Itnig)

APIwebREST

Page 9: Api Design and More (Friday Training at Itnig)

we want APIs that are easy to understand, consume, extend and scale

Page 10: Api Design and More (Friday Training at Itnig)

designimplementationdeploymentscalingAPI

Page 11: Api Design and More (Friday Training at Itnig)

designimplementationdeploymentscalingretirement

API

Page 12: Api Design and More (Friday Training at Itnig)

designimplementationdeploymentscaling

APIREAL SCALE

Page 13: Api Design and More (Friday Training at Itnig)

#protipdocument it first

Page 14: Api Design and More (Friday Training at Itnig)

alternativethrow v1 as soon as you finish it

Page 15: Api Design and More (Friday Training at Itnig)

designimplementationdeploymentscalingAPI

Page 16: Api Design and More (Friday Training at Itnig)

HTTP REST URI METHODS STATUS METADATA REPRESENTATION SECURITY VERSIONING PAGINATION

Page 17: Api Design and More (Friday Training at Itnig)

HTTPHyperText Transfer Protocol - OSI lvl 7

learn to love it

use proper URIs, methods, status codes, request and response headers, ...

Page 18: Api Design and More (Friday Training at Itnig)

RESTREpresentational State Transfer

Resources are first class citizensResources have unique representationsCommunication is stateless

Page 19: Api Design and More (Friday Training at Itnig)

URIUniform Resource Identifier

scheme://authority/path?query#fragment

http://api.sports.com/sports/soccer/teams/fcbarcelona/players?max_age=24

Page 20: Api Design and More (Friday Training at Itnig)

URIs are resource

identifiersnot just a path to a server action

Page 21: Api Design and More (Friday Training at Itnig)

BAD URIshttp://toster.ru/posts/http://toster.ru/posts/first_posthttp://toster.ru/posts/Hellohttp://toster.ru/posts.json

Page 22: Api Design and More (Friday Training at Itnig)

BAD URIshttp://toster.ru/posts/http://toster.ru/posts/first_posthttp://toster.ru/posts/Hellohttp://toster.ru/posts.json

trailing slash

file extension

upper case

underscore

Page 23: Api Design and More (Friday Training at Itnig)

GOOD URIshttp://toster.ru/blogs/jordi/posts/api-designhttp://toster.ru/blogs/jordi/postshttp://toster.ru/blogs/jordihttp://toster.ru/blogs

Page 24: Api Design and More (Friday Training at Itnig)

GOOD URIshttp://toster.ru/blogs/jordi/posts/api-designhttp://toster.ru/blogs/jordi/postshttp://toster.ru/blogs/jordihttp://toster.ru/blogs hierarchical

resource identifierI see what you did there

Page 25: Api Design and More (Friday Training at Itnig)

HTTP methodsGET POST PUT DELETE HEAD PATCH ...

Also called “Verbs”

Together with a URI they tell the API what to do

Page 26: Api Design and More (Friday Training at Itnig)

GETHEAD

PUTPOST

DELETEPATCH

retrieve a resource representation

get only the headers, no body

update a resource

create a resource, execute controllers

remove a resource

partially update a resourcemore...

Page 27: Api Design and More (Friday Training at Itnig)

Response statuses1xx 2xx 3xx 4xx 5xx

Do not limit to 200, 404 and 500RTFM Specifications

Page 28: Api Design and More (Friday Training at Itnig)

MetadataUseful req/res information in the headers

Content-TypeContent-LengthLast-ModifiedEtagLocation

Cache-ControlExpiresDatePragmaCustom, ...

Page 29: Api Design and More (Friday Training at Itnig)

MetadataUseful req/res information in the headers

Content-TypeContent-LengthLast-ModifiedEtagLocation

Cache-ControlExpiresDatePragmaCustom, ...

MORE ON THAT LATER

Page 30: Api Design and More (Friday Training at Itnig)

SecurityProtect private resources

OAuth is the most common option right nowBasic HTTP Authentication also worksSSL is not optional

Page 31: Api Design and More (Friday Training at Itnig)

VersioningAPIs should evolve without breaking

example.com/api/v3/posts BADv3.api.example.com/posts OK

Accept: application/vnd.example.v3+json GOOD

Page 32: Api Design and More (Friday Training at Itnig)

PaginationReturn a partial collection

example.com/posts/pages/2 BADexample.com/posts?page=2&per_page=20 GOOD

Page 33: Api Design and More (Friday Training at Itnig)

designimplementationdeploymentscalingAPI

Page 34: Api Design and More (Friday Training at Itnig)

code!

Page 35: Api Design and More (Friday Training at Itnig)

code!ideally with BDD

Page 36: Api Design and More (Friday Training at Itnig)

Ruby on RailsSinatra — Rubyexpress — node.js∞ options...

Page 37: Api Design and More (Friday Training at Itnig)

abstract the backing services as much as possible

Page 38: Api Design and More (Friday Training at Itnig)

do only what’s critical while building a response.everything else must be async

Page 39: Api Design and More (Friday Training at Itnig)

designimplementationdeploymentscalingAPI

Page 40: Api Design and More (Friday Training at Itnig)

stateless processesany process is good

Sessions can go to Redis, Memcached, ...State must go on stateful processes (database)

Page 41: Api Design and More (Friday Training at Itnig)

disposable processeslicense to kill’em

Processes being stateless and disposable, it’s easy to avoid memory bloat and scale out

Page 42: Api Design and More (Friday Training at Itnig)

structured processesapp servers, workers, web servers, ...

It’s important to separate processes by their primary task

Page 43: Api Design and More (Friday Training at Itnig)

designimplementationdeploymentscalingAPI

Page 44: Api Design and More (Friday Training at Itnig)

horizontal scalingis inexpensive

If more load can be handled by more processes

Page 45: Api Design and More (Friday Training at Itnig)

horizontal scalingis inexpensive not really

If more load can be handled by more processes:

it scales!

Page 46: Api Design and More (Friday Training at Itnig)

application cachingdon’t do things twice

Never calculate things twice. Do it once, store it.Redis, Memcached, I’m looking at you.

Page 47: Api Design and More (Friday Training at Itnig)

HTTP cachingsave bandwidth, cut response time

Use HTTP headers to define the response’s cacheability, expiration, validity, ...

Take advantage of Varnish, Squid, ...

Page 48: Api Design and More (Friday Training at Itnig)

database replicationfaster reads is a big win

If your API serves more reads than writes, send the reads to read-only slaves of the database

Page 49: Api Design and More (Friday Training at Itnig)

delay async tasksresponse time is everything

If you didn’t before, do it now

Page 50: Api Design and More (Friday Training at Itnig)

designimplementationdeploymentscalingAPI

Page 51: Api Design and More (Friday Training at Itnig)

APIdesign and more

Page 52: Api Design and More (Friday Training at Itnig)

thank you

Page 53: Api Design and More (Friday Training at Itnig)

thank youспасибо

Page 54: Api Design and More (Friday Training at Itnig)

slides available atjrom.net/api-design-and-more