Building robust mobile clients

API Days Berlin 2014

Transcript

1. BUILDING ROBUST MOBILE CLIENTS View from the other side Zdenek Nemec – @zdne Apiary.io
2. API BLUEPRINT APIARY iOS Developer ABOUT ME Zdenek Nemec – @zdne
3. WHY TALK CLIENTS?
4. • To attract clients? • To retain clients? • API is user interface • It takes two to tango WHY TALK CLIENTS?
6. API Blueprint • Designed to enable and encourage the talk about an API before it is even made • Common parlance for server and client developers
7. Mock > Use > Implement Documentation Automated testing
8. WHY TALK MOBILE?
9. WHY TALK MOBILE? • Spending more time on mobile vs. desktop
10. WHY TALK MOBILE? • People are using Apps rather than Web
11. WHY TALK MOBILE? “In 2013, the number one reason APIs are deployed, is to support mobile development.” ! – Kin Lane
12. CLIENT CONCERNS
13. • What this APIs delivers? (features, benefits) • How much it will costs? • Performance • Availability CLIENT CONCERNS
14. • Will it break in a month? (longevity) • How much work it is? (laziness) CLIENT CONCERNS
15. LONGEVITY
16. • Apple reviews every App submission (version) • It takes time (usually ~1-2 weeks) • "Breaking" API implies client users are left in the dark for 2-3 weeks • This is not acceptable LONGEVITY iOS client perspective
17. • Clients in the field are very fragile • Susceptible to API changes • Mantra: Don't break the clients • But how to evolve? • How to wipe the slate clean? LONGEVITY
18. LONGEVITY VS. EVOLUTION
21. • We break you in two years time… • Should I ship client 2 months before its death? • Should I be afraid my client will break? • What about the rest of the API? • Wipe the slate clean every two years (or not) LONGEVITY VS. EVOLUTION
23. We can do better.
24. PROMISES
25. • We can … • Resilient clients • API that can evolve • Tune communication without redeploying clients • Move fast! • Less code! • Less maintenance • Less worries • Better life and everything* PROMISES * your results may vary
27. OK, HOW?
28. DECOUPLING
29. BUT DIDN’T YOU SAY…
31. YES, BUT NOT AS A TIGHT COUPLE
33. • Let everyone do his / her part • Do not make assumptions about the counterpart implementation • Do not reimplement server logic in your client • Let server drive your interactions with resources • Focus on domain semantics DECOUPLING
34. DEMO: FIZZBUZZ
35. FIZZBUZZ "Write a program that prints the numbers from 1 to 100. But for multiples of three print Fizz instead of the number and for the multiples of five print Buzz. For numbers which are multiples of both three and five print FizzBuzz.”
36. FIZZBUZZ 1: 1 2: 2 3: Fizz 4: 4 5: Buzz 6: Fizz 7: …
37. • Author: Stephen Mizell (@Stephen_Mizell) • Read Stephen’s blog! ! • Server knows how to calculate FizzBuzz for given number • Server knows what is the next FizzBuzz • Clients may decide what is the step and at what number to end FBAAS FizzBuzz as a Service
38. DETOUR: RESOURCE
39. RESOURCE “Any information that can be named can be a resource: a document or image, a temporal service (e.g. today's weather in Los Angeles)” ! ! – Roy Fielding
40. • Properties – attributes, data, semantic descriptors • Affordances – actions, relations, what operation(s) the resource “affords” RESOURCE Properties Affordances URI (+ query parameters) Resource
41. RESOURCE ORIENTED • Thinking in the terms of: • resources • relations between resources • resource properties • resource affordances • API as a state machine • Resource-oriented empowers decoupling
42. We are interacting with resources through their representations.
43. FIZZBUZZ RESOURCE Properties answer: 1 Affordances next: /fizzbuzz?number=2 /fizzbuzz{?number,step,endAt} FizzBuzz Resource number: 1
44. COUPLED APPROACH 1: for i in 1..100 2: answer = GET /fizzbuzz?number=i 3: print answer • Why is this coupled: • tied to a particular URL • iteration makes assumptions over the result (consider returning multiple results)
45. COUPLED APPROACH 1: while i < END 2: answer = GET /fizzbuzz?number=i 3: print answer 4: i = i + STEP • Why is this coupled: • duplicates servers logic adding two numbers • keeps track of the end
46. DECOUPLED APPROACH 1: answer = root.follow(“first”) 2: print answer 3: while answer.hasLink(“next”) 4: answer = answer.follow(“next”, step: STEP, end: END) 5: print answer • Why is this decoupled: • No hardcoded URLs • No logic about the algorithm • Completely driven by the resource
47. DECOUPLED APPROACH • Without redeploying clients we can: • change URLs / API topology • change the algorithm • change the number of API calls (through embedding)
48. EMBEDDED RESOURCES • Several resource representation allows embedding of other resources (partial or full) • When following a link check embedded resources first • Reduce number of API calls from 100 to just 2!
49. GENERIC CLIENTS
50. GENERIC CLIENTS • Apparently we need a “new” client software • Understand HTTP • Understand representations (links, relations, embedded resources) • Surf the API • Generic clients can be reused by specific clients • Specific clients just needs to understand API domain semantics.
51. GENERIC CLIENTS • You do not have to write it by yourself • Early implementations exists • HyperResource • SHMkit • ObjectiveHal • + many more
52. MORE ABOUT FIZZBUZZ • Stephen Mizell blog: http://smizell.com/ weblog/2014/solving-fizzbuzz-with- hypermedia ! • Steve Klabnik followup: http:// words.steveklabnik.com/hypermedia- fizzbuzz
53. SEE THE BENEFITS • GitHub Gist iOS Client • One hardcoded URL • Driven by the server • Client just understands (some of) the semantics
54. It takes two to tango.
55. USE GENERIC CLIENTS
56. DEMAND REASONABLE API DESIGN NOW!
58. • http://apiary.io • http://apiblueprint.org • http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/ • http://apievangelist.com • http://smizell.com • http://smizell.com/weblog/2014/solving-fizzbuzz-with-hypermedia • http://words.steveklabnik.com/hypermedia-fizzbuzz • http://petegamache.com/wsrest2014-gamache-slides.pdf • https://github.com/gamache/hyperresource • http://www.slideshare.net/KevinONeill1/hypermedia-for-the-ios- developer-swipe-2012 • http://www.slideshare.net/royfielding/evolve13-keynote-scrambled- eggs • http://www.mnot.net/blog/2011/10/25/ web_api_versioning_smackdown? utm_content=bufferf07f9&utm_source=buffer&utm_medium=twitter &utm_campaign=Buffer REFERENCE
59. • http://www.flickr.com/photos/polishsausagequeen/2178265710/ • http://www.flickr.com/photos/breannajosephine/5265280328/sizes/l/ • http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/ • http://techcrunch.com/2014/04/30/facebook-api-guarantee/ • http://comicbook.com/blog/2013/01/31/the-big-bang-theory-spoiler- does-sheldon-actually-sleep-with-amy/ • http://knowyourmeme.com/memes/shut-up-and-take-my-money PHOTO CREDITS