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

Beyond REST: Web Services Designed for Mobile

Beyond REST: Web Services Designed for Mobile

Creating the best possible mobile experience extends beyond the device to the services your app depends on. The unique constraints imposed by mobile devices should influence your API design. Learn how to build great mobile web services, what REST doesn't cover, and lessons from years of experience designing and refining mobile web services.

Sam Kirchmeier

April 11, 2015
Tweet

More Decks by Sam Kirchmeier

Other Decks in Programming

Transcript

  1. WHY REVIEW REST? Defines our constraints It might not be

    what you think it is It’s really cool
  2. REST Representational State Transfer Coined by Roy Fielding in 2000

    The architectural style of the web Deduced from and tested by the web itself
  3. “[REST] has allowed Web-based applications to scale from 100,000 requests

    per day in 1994 to 600,000,000 requests per day in 1999.” –Roy Fielding Source: https://www.ics.uci.edu/~fielding/pubs/dissertation/conclusions.htm
  4. 0 2,250,000,000 4,500,000,000 6,750,000,000 9,000,000,000 1999 (Everything) 2015 (Just YouTube)

    REQUESTS PER DAY Source: http://www.internetlivestats.com/one-second/#youtube-band
  5. “What needs to be done to make the REST architectural

    style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?” –Roy Fielding, 2008 Source: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
  6. HATEOAS Client doesn’t need a manual Client doesn’t know URL

    formats Client doesn’t know available states
  7. HATEOAS Client doesn’t need a manual Client doesn’t know URL

    formats Client doesn’t know available states Works for more than just read-only data
  8. 1 2

  9. “There is so much coupling on display that it should

    be given an X rating.” –Roy Fielding Source: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
  10. “REST isn’t an all or nothing proposition. One can get

    significant value from partial adoption.” –Sam Ruby Source: http://www.intertwingly.net/blog/2008/10/21/Progressive-Disclosure
  11. FOR DEVELOPERS DOCUMENTATION Treat it like any other feature Must

    be up-to-date Good: Auto-validate Better: Auto-generate
  12. FOR DEVELOPERS DOCUMENTATION Treat it like any other feature Must

    be up-to-date Good: Auto-validate Better: Auto-generate Critical for developer happiness
  13. FOR DEVELOPERS DOCUMENTATION Reference Docs Authentication Version Details Request Headers

    Response Headers Response Format Status Codes Backwards Compatibility Pagination Resources Methods Method Parameters Example Requests Example Responses Error Format
  14. FOR DEVELOPERS CONSISTENCY Don’t deviate from the norm Use standard

    HTTP verbs GET Get a resource POST Create a resource PUT Replace a resource PATCH Update a resource DELETE Delete a resource
  15. FOR DEVELOPERS CONSISTENCY Use standard HTTP status codes 200 Success

    201 Created 400 Bad request 401 Unauthorized 404 Not found 422 Unprocessable entity 500 Server error
  16. FOR DEVELOPERS CONSISTENCY Backwards compatibility Publish your contract Adding new

    stuff is OK Removing stuff is not OK :( Making a backwards-incompatible change creates a new version of the API
  17. FOR DEVELOPERS CONSISTENCY How Stripe handles versions Backwards compatibility is

    “hidden” New users are on the latest version Stripe adds breaking changes with gates
  18. FOR DEVELOPERS CONSISTENCY How Stripe handles versions Backwards compatibility is

    “hidden” New users are on the latest version Stripe adds breaking changes with gates Users can update to the latest anytime
  19. FOR DEVELOPERS TESTABLE Web APIs must be testable Minimum: Staging,

    Sandbox, or Test Mode Better: Developers run a local server
  20. PATTERNS KILL SWITCH Hypothetical situation You have an app in

    the App Store You discover a bug and start fixing it
  21. PATTERNS KILL SWITCH Hypothetical situation You have an app in

    the App Store You discover a bug and start fixing it Meanwhile, end users also discover it
  22. PATTERNS KILL SWITCH Hypothetical situation You have an app in

    the App Store You discover a bug and start fixing it Meanwhile, end users also discover it You’re helpless for 1 or 2 weeks
  23. PATTERNS KILL SWITCH Hypothetical situation You have an app in

    the App Store You discover a bug and start fixing it Meanwhile, end users also discover it You’re helpless for 1 or 2 weeks Alert them
  24. PATTERNS SOURCE OF TRUTH The server is always the source

    of truth Except when it isn’t What about when resources are created?
  25. PATTERNS SOURCE OF TRUTH The server is always the source

    of truth Except when it isn’t What about when resources are created? What about airplane mode?
  26. Pushpin GET /stream 200 OK chunked GET /stream Open #channel

    Publish #channel Publish #channel Publish #channel POST /like POST /like POST /like
  27. Pushpin GET /stream 200 OK chunked GET /stream Open #channel

    Publish #channel Publish #channel Publish #channel POST /like POST /like POST /like
  28. Pushpin GET /stream 200 OK chunked GET /stream Open #channel

    Publish #channel Publish #channel Publish #channel POST /like POST /like POST /like