Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Scenario Driven API Design (Apidays Paris)

Ivo Jansch
December 02, 2014

Scenario Driven API Design (Apidays Paris)

In this talk we will look at an approach to API design that I have been practicing and refining for the past couple of years. We will look at what Scenario Driven Design means, when it is useful, and what the advantages and disadvantages are, when comparing this design approach with other API design methodologies. We will see how it will aid developers that need to create APIs for a large range of devices and offer advice on how to create APIs that are useful and usable.

Ivo Jansch

December 02, 2014
Tweet

More Decks by Ivo Jansch

Other Decks in Technology

Transcript

  1. http://www.egeniq.com [email protected] @egeniq APIDays Paris, December 2, 2014 Ivo Jansch

    Scenario Driven API Design Or: how to make more usable APIs
  2. About Me @ijansch Entreprenerd (@egeniq / @buildozerapp) App & Api

    Developer Author & Speaker Upcoming: 
 http://leanpub.com/nways Conference Organizer (@endpointcon / @mdevcon) 2
  3. A few months ago: “We have some issues. Can you

    fix our performance problem?” 5 An interesting, anonymous case
  4. REST API (PHP) Their design 6 SQL database Models Controllers

    Views /orders /products /orders/:id/products /products/:id etc
  5. Website (YUI) REST API (PHP) The design 7 SQL database

    Models Controllers Views API client Models Controllers Views
  6. What did a trace show? 1 dashboard page 26 API

    calls 124 objects passed between api and client 8
  7. Website (YUI based) REST API (PHP based) Problem 10 SQL

    database Models Controllers Views API client Models Controllers Views 1x 26x
  8. Website REST API Problem 11 SQL database THIN BUSINESS LOGIC

    Controllers Views API client THICK BUSINESS LOGIC Controllers Views
  9. Something went terribly wrong 12 SELECT * FROM order WHERE

    id = 2 orderBean.selectById(2) $orderModel->getOrder(2) http://api/orders/2 RESTful APIs
  10. Website REST API What if we add even more clients?

    14 SQL database THIN BUSINESS LOGIC Controllers Views API client THICK BUSINESS LOGIC Controllers Views Mobile Client?
  11. Important This is not a REST problem. REST is a

    great way to expose an API. 15
  12. Scenario Driven Design ‣1. Client analysis ‣Identify client needs ‣Usage

    scenarios ‣2. Service design ‣Optimal ways to service the client scenarios ‣3. Data modelling ‣Create data model to support the scenario’s ‣Low level and high level concepts ‣4. Interface design ‣REST/HAL etc. interface ‣Versioning, etc. 22
  13. Typical VOD features 25 My rented movies Featured movies Featured

    movie collections Recommendations Popular movies
  14. Would this work? ‣Data Driven: ‣GET /movies/:id ‣GET /tickets ‣GET

    /users/:id ‣Yes it would work ‣but we would easily get stuck with the ’26 api calls’ problem 26
  15. Scenario Driven Design ‣Identify all relevant scenarios: ‣Order a movie

    ‣Watch a movie ‣See list of my movies ‣Promote content on the home screen ‣See what’s available ‣Like/unlike movies ‣Interactions are platform-specific, scenarios usually aren’t. 27
  16. “Promote content on the home page” ‣All clients should present,

    on their home screen, after login: ‣The user’s most recently rented movies ‣User specific recommendations ‣Movie top 20 ‣Featured movies 28
  17. Scenario Driven Design 30 Data Modeling API interface Specific/Generic Clients

    Service Design 2. Promote content on the home screen 1. ’home’ screen
  18. Scenario Driven Design 32 Data Modeling API interface Specific/Generic Clients

    Service Design 2. Promote content on the home screen 3. Movies, collections, banners 1. ’home’ screen
  19. Scenario Driven Design 33 Data Modeling API interface Specific/Generic Clients

    Service Design 2. Promote content on the home screen 3. Movies, collections, banners 4. /promoslots/home 1. ’home’ screen
  20. Consider scenario’s at the highest level ‣GET /users/@me/dashboard ‣High Level

    Scenario ‣Business Logic entirely API side ‣Important: find balance between generic and specific 35
  21. Wise Words ‣Eric S. Raymond: “Smart data and dumb code

    works a lot better than the other way around” (from: The Cathedral & The Bazaar) ‣In 2014 this means: 
 
 Smart APIs, dumb clients 36
  22. Client REST API Business Logic where it belongs 37 Data

    BUSINESS LOGIC Controllers Views API client Controllers Views Look mum, no business logic!
  23. A word about tool vendors 41 Data Modeling Interface Design

    Specific/Generic Clients Service Design db vendor space (commoditised ~ 16 years ago) api tool vendor space (to be commoditised) you