Slide 1

Slide 1 text

http://www.egeniq.com [email protected] @egeniq Zendcon Europe, November 19, 2013 Ivo Jansch Scenario Driven API Design Or: the one with rants about REST Or: the one with Zombies, Coffee, Beer, Elephpants & Bacon

Slide 2

Slide 2 text

About Me @ijansch Entreprenerd Mobile & Web Developer Author & Speaker ! http://joind.in/9265 !2

Slide 3

Slide 3 text

About Egeniq Mobile Development Knowledge Distributed ! ! ! ! ! ! !3

Slide 4

Slide 4 text

Unfortunately most people don’t read beyond: ! VERBS Get, Post, Put, Delete ! RESOURCES The stuff you work with. !4 The Problem with REST

Slide 5

Slide 5 text

Resources, like bacon !5 POST /bacon GET /bacon PUT /bacon DELETE /bacon

Slide 6

Slide 6 text

A few months ago: ! “We have some issues. Can you fix our performance problem?” !6 An interesting, anonymous case

Slide 7

Slide 7 text

REST API (ZF based) Their design !7 SQL database Models Controllers Views /orders /products /orders/:id/products /products/:id etc

Slide 8

Slide 8 text

Website (ZF/YUI based) REST API (ZF based) The design !8 SQL database Models Controllers Views API client Models Controllers Views

Slide 9

Slide 9 text

The feature “A dashboard showing the user’s open orders, the order status, one product for each order plus the thumb, and a list of the last 5 sent orders” ! ! Order: 12314 Dispatched Zombie King !9

Slide 10

Slide 10 text

What did a trace show? 1 dashboard page ! 26 API calls ! 124 objects passed between api and client !10

Slide 11

Slide 11 text

WTF ! “No. I can not fix your performance problem” !11

Slide 12

Slide 12 text

Website (ZF/YUI based) REST API (ZF based) Problem 1 !12 SQL database Models Controllers Views API client Models Controllers Views 1x 26x

Slide 13

Slide 13 text

Website REST API Problem 2 !13 SQL database THIN BUSINESS LOGIC Controllers Views API client THICK BUSINESS LOGIC Controllers Views

Slide 14

Slide 14 text

Something went terribly wrong !14 SELECT * FROM order WHERE id = 2 orderBean.selectById(2) $orderModel->getOrder(2) http://api/orders/2 RESTful APIs

Slide 15

Slide 15 text

OMG ! Give the monkey a screwdriver. Prepare to get hurt. !15

Slide 16

Slide 16 text

Website REST API Problem 3 !16 SQL database THIN BUSINESS LOGIC Controllers Views API client THICK BUSINESS LOGIC Controllers Views Mobile Client?

Slide 17

Slide 17 text

Important REST is NOT an excuse to expose your raw data model !17

Slide 18

Slide 18 text

Important REST is NOT an excuse to stop thinking about business logic !18

Slide 19

Slide 19 text

Very Important REST IS NOT THE PROBLEM. ! YOU ARE. ! (well, at least if you’re the dude that coded that API from the anonymous example) ! (Yes, I know who you are) !19

Slide 20

Slide 20 text

It doesn’t have to end this way Just think the API through !20

Slide 21

Slide 21 text

Scenario Driven Design ‣How is your API going to be used ‣Usage scenarios ! ‣Don’t call it REST (yet) if that’s too scary • HTTP API, JSON API, ... !21

Slide 22

Slide 22 text

Teach by example: Pathé Thuis !22 Zombies

Slide 23

Slide 23 text

Big ecosystem, lots of clients !23 API ipad tv web xbox android ???

Slide 24

Slide 24 text

Scenarios ‣Order a movie ‣Watch a movie ‣See list of my movies ‣See what’s available !24

Slide 25

Slide 25 text

Scenario: view available movies !25 My zombie movies Featured movies Featured movie collections Recommendations Popular movies

Slide 26

Slide 26 text

Would this work? ‣GET /movies/:id ‣GET /tickets ‣GET /users/:id !26

Slide 27

Slide 27 text

This would work better: ‣/recommendations • or /users/@me/recommendations ‣/promoslots ‣/users/@me/movies ‣/users/@me/movies/liked !27 Interesting concept: Pseudo identifiers compound resources views

Slide 28

Slide 28 text

Consider the scenario again ‣All clients should present, on their home screen, after login: ‣The user’s 3 most recently rented movies ‣User specific recommendations ‣Movie top 20 ‣Featured movies !28

Slide 29

Slide 29 text

All clients must implement this feature !29 API ipad tv web xbox android ???

Slide 30

Slide 30 text

Ergo: ‣GET /users/@me/dashboard ! ! ‣High Level Scenario ‣Business Logic entirely API side !30

Slide 31

Slide 31 text

Ergo: ‣Eric S. Raymond: “Smart data and dumb code works a lot better than the other way around” (from: The Cathedral & The Bazaar) ! ‣In 2013 this means: 
 
 Smart APIs, dumb clients !31

Slide 32

Slide 32 text

Client REST API Approach, visualised !32 SQL database BUSINESS LOGIC Controllers Views API client Controllers Views Look mum, no business logic!

Slide 33

Slide 33 text

Consider This API Usability over API RESTfulness ! or ! Scenarios first, formatting second !33

Slide 34

Slide 34 text

Fat resources { "promoslots": [{
 "position": "home",
 "movies": [{ "id": 1012, "title": "Zombie Apocalypse", ... },{
 "id": 1020,
 "title": "Zombie Reloaded”,
 ...
 }] }] } !34

Slide 35

Slide 35 text

Compound resources { "promoslots": [{
 "position": "home",
 "movies": [1012,1024,942] }], "movies": [{ "id": 1012, "title": "Zombie Apocalypse", ... }] } !35

Slide 36

Slide 36 text

Smart responses { "total": 100,
 "count": 10,
 "promoslots": [{
 "position": "home",
 "movies": [{ "id": 1012,
 "href": "http://api.example.com/movies/1012" "title": "Zombie Apocalypse", ... },{
 "id": 1020,
 "href": "http://api.example.com/movies/1020"
 "title": "Zombie Reloaded”,
 ...
 }] }] } !36

Slide 37

Slide 37 text

Actions for clarity ‣If you don’t have enough verbs ‣If you don’t like • ‘POST /users/@me/movies/1012/likes’ ‣CHEAT: • /movies/1012/;like • /movies/1012/;unlike ! (but don’t tell @dzuelke) !37

Slide 38

Slide 38 text

Standardisation JSON-API
 http://jsonapi.org ! ! HAL http://stateless.co/hal_specification.html !38

Slide 39

Slide 39 text

Creating Scenario Driven APIs Or at least how we do it !39

Slide 40

Slide 40 text

Our approach to API designs ‣Research usage scenarios ‣Create resource map ‣Generate rewrite rules ‣Use Zend MVC • without dynamic routing • with lightweight Zend_Application • (With Symfony DI by the way) ‣Validate API !40

Slide 41

Slide 41 text

Create resource map !41

Slide 42

Slide 42 text

Create resource map !42

Slide 43

Slide 43 text

Generate rewrite rules !43

Slide 44

Slide 44 text

Write controllers !44

Slide 45

Slide 45 text

Documentation generation ‣Using Mike van Riel’s phpDocumentor tools ! ! ! ! ! ! ! !45

Slide 46

Slide 46 text

‣Also using Mike’s phpDocumentor tools ! ! ! ! ! ! ! API validation !46

Slide 47

Slide 47 text

Something you probably should look at ! ! http://apigility.org !47

Slide 48

Slide 48 text

The best way to eat the elephant standing in your path is to cut it up into little pieces African Proverb !48

Slide 49

Slide 49 text

Myth 1 I don’t know how my API will be used !49

Slide 50

Slide 50 text

Myth 2 If my features change, my entire API must change !50

Slide 51

Slide 51 text

Myth 3 This talk is an anti REST talk !51

Slide 52

Slide 52 text

Remember YOU ARE NOT ! ! ! (unless you are) !52

Slide 53

Slide 53 text

Thank you! Questions? http://www.egeniq.com [email protected] @egeniq http://www.egeniq.com [email protected] @ijansch http://joind.in/9265

Slide 54

Slide 54 text

Credits ‣ ‘Mom, willie took my teat again’ by Woodlywonderworks - http://www.flickr.com/ photos/wwworks/275200442 ‣ ‘Bacon in the oven’ by Joel Kramer - http://www.flickr.com/photos/ 75001512@N00/4612278861 ‣ ’3 pounds of goodness’ by Robert S. Donovan - http://www.flickr.com/photos/ 10687935@N04/7997980826 ‣ ‘Eating the bacon’ by Beatrice Murch - http://www.flickr.com/photos/ 82439748@N00/5070496311 ‣ ‘David Zuelke’ by Sebastian Bergmann - http://www.flickr.com/photos/ 90237600@N00/4065324036 ‣ ‘ElePHPants’ by Sebastian Bergmann - http://www.flickr.com/photos/ sebastian_bergmann/2338238596/ ‣ ‘Beer candles from Ghent’ by Guy Renard - http://www.flickr.com/photos/ 72116883@N00/6933441530 ‣ ‘Nein nein nein das ist verboten’ slide by Davis Zuelke - http:// munich2012.drupal.org/sites/default/files/slides/ drupalconmunich2012_http_rest_0.pdf