Mobile API. Design & Techniques.

Transcript

1. Mobile API Design & Techniques. Fred Brunel CTO Wednesday, 29

   February, 12

2. Wednesday, 29 February, 12

3. Wednesday, 29 February, 12

4. Wednesday, 29 February, 12

5. Why? Wednesday, 29 February, 12

6. Though for CPU power Though for bandwidth Lazy designed. Too

   close to database. Wednesday, 29 February, 12

7. A mobile device is Low powered Low bandwidth Runs on

   battery! Wednesday, 29 February, 12

8. A the network is the weak link. Wednesday, 29 February,

   12

9. Network conditions change in real-time. Wednesday, 29 February, 12

10. We want to keep the best user experience at all

    time. Nobody wants an unresponsive app. Wednesday, 29 February, 12

11. The features of an API has a huge impact on

    performances. Wednesday, 29 February, 12

12. An API is a contract that dictates what can or

    cannot be done (directly). Wednesday, 29 February, 12

13. When the API is too lazy, or incomplete; the burden

    is put on the mobile app. Wednesday, 29 February, 12

14. Any workaround put a stress on the mobile app to

    use too much network. Wednesday, 29 February, 12

15. API = User Interface. Should be simple and get the

    job done. Fast. Wednesday, 29 February, 12

16. Landlord Report. Wednesday, 29 February, 12

17. Simple Standard Complete Wednesday, 29 February, 12

18. Simple Standard Complete SOAP XML-RPC WS-* Pure REST Wednesday, 29

    February, 12

19. Simple Complete Wednesday, 29 February, 12

20. Trust the OSI model. Works everywhere. And it’s plenty enough.

    http://en.wikipedia.org/wiki/OSI_model Wednesday, 29 February, 12

21. REST-ish API + JSON Pure REST is a nice to

    have but not a goal. Wednesday, 29 February, 12

22. GET/POST + Action + Params is fine. PUT/DELETE are nice

    to have. Wednesday, 29 February, 12

23. Twitter is also REST-ish POST statuses/create POST statuses/destroy/:id POST statuses/update

    Wednesday, 29 February, 12

24. REST put an emphasis on actions applied to resources; but

    the issue is the representation. Wednesday, 29 February, 12

25. Simplify the life of the implementor. Be pragmatic. Wednesday, 29

    February, 12

26. When designing your API payloads, pay attention to consistency and

    completeness. Wednesday, 29 February, 12

27. Consistency means developer know what to expect. Principle of least

    astonishment. Wednesday, 29 February, 12

28. Completeness means less roundtrips. Wednesday, 29 February, 12

29. HTTP latency on 3G ~ 1 second. Every request count.

    Wednesday, 29 February, 12

30. API is NOT a CRUD interface to your SQL database.

    It’s a facade. Wednesday, 29 February, 12

31. Database Facade API App Data Representation Raw Data Display Wednesday,

    29 February, 12

32. The facade answer to high-level questions. Think services, not objects

    and methods. Wednesday, 29 February, 12

33. So, how do we start from here? Wednesday, 29 February,

    12

34. Most of the time, a mobile API will be use

    to get information to be displayed on a screen. Wednesday, 29 February, 12

35. Reverse Design. Start from the UI Not the data Wednesday,

    29 February, 12

36. 1. Think screens 2.Entities to display 3.Design entity models 4.Design

    services Wednesday, 29 February, 12

37. Wednesday, 29 February, 12

38. ID Title Town Country Rating Thumbnail URL Geocode Website Email

    Description Wednesday, 29 February, 12

39. Then, format the representation to be as efficient as possible.

    Wednesday, 29 February, 12

40. Each JSON entity should have the same consistent representation. Wednesday,

    29 February, 12

41. "person": { "id": 1234, "name": "Fred", "lastname": "Brunel", "company": "WhereCloud"

    } Wednesday, 29 February, 12

42. "book": { "name": "Steve Jobs", "author": "Walter Isaacson", "lenders" =

    [{ "person_id": 1234, "person_name": "Fred", "person_lastname": "Brunel" }] } BAD Wednesday, 29 February, 12

43. "book": { "name": "Steve Jobs", "author": "Walter Isaacson", "lenders" =

    [{ "id": 1234, "name": "Fred", "lastname": "Brunel" }] } GOOD Wednesday, 29 February, 12

44. ... "user_mentions": [{ "id": 22548447, "id_str": "22548447", "screen_name": "rno", "name":

    "Arnaud Meunier", "indices": [0, 4] ]} ... Wednesday, 29 February, 12

45. Pick the right granularity. Denormalize! Wednesday, 29 February, 12

46. "result": { ... "categories" = [{ "id": 2 }], "images":

    [{ "id": 317171 }], "tags": [{ "id": 555 }] ... } Wednesday, 29 February, 12

47. "result": { ... "categories": [{ "id": 2 "name" = "food"

    }], "images" = [{ "id": 317171 "url": "http://image.com/a.png" }], ... } Wednesday, 29 February, 12

48. Denormalize the most common fields. Avoid unnecessary roundtrips. Wednesday, 29

    February, 12

49. Don’t make the app connects to 10 3rd- party systems.

    Aggregate on the backend. Wednesday, 29 February, 12

50. The backend has the power, bandwidth and knowledge. Use it!

    Wednesday, 29 February, 12

51. Make it fast! Some good techniques to be aware of.

    Wednesday, 29 February, 12

52. JSON is fast to parse, but still, compress everything. Wednesday,

    29 February, 12

53. Use Cache-Control on every response that can be cached. Wednesday,

    29 February, 12

54. Partial Responses & Partial Updates Let the client decides what

    to get/update. Wednesday, 29 February, 12

55. GET http://www.google.com/calendar/ feeds/[email protected]/private/ full?fields=entry(title,gd:when) Wednesday, 29 February, 12

56. PATCH /myfeed/1/1/ Content-Type: application/xml <entry xmlns='http://www.w3.org/2005/Atom' xmlns:gd='http://schemas.google...' gd:fields='description'> <title>New title</title>

    </entry> Wednesday, 29 February, 12

57. Batch Requests Send multiple operations, get one answer. Wednesday, 29

    February, 12

58. Persistent Connections. Keep a connection nailed up. Wednesday, 29 February,

    12

59. “If you’re serious about network, you should make your own

    protocol.” —Fake Alan Kay. Wednesday, 29 February, 12

60. The fabric of the Internet is TCP/IP, not HTTP. Wednesday,

    29 February, 12

61. Make your own Binary Protocol. Lot faster than text +

    compression. Sorry! Wednesday, 29 February, 12

62. Message-based API Custom TLV MessagePack ProtocolBuffers Wednesday, 29 February, 12

63. TAG LENGTH VALUE 32 bits 16 bits n bits TLV

    TLV TLV TLV TLV TLV TLV TLV TLV TLV messages streaming a message Wednesday, 29 February, 12

64. message Person { required string name = 1; required int32

    id = 2; optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { required string number = 1; optional PhoneType type = 2 [default = HOME]; } repeated PhoneNumber phone = 4; } Wednesday, 29 February, 12

65. Person person; person.set_name("John Doe"); person.set_id(1234); person.set_email("[email protected]"); fstream output("myfile", ios::out |

    ios::binary); person.SerializeToOstream(&output); fstream input("myfile", ios::in | ios::binary); Person person; person.ParseFromIstream(&input); cout << "Name: " << person.name() << endl; cout << "E-mail: " << person.email() << endl; Wednesday, 29 February, 12

66. So. They are tons of efficient solutions and techniques. Wednesday,

    29 February, 12

67. Remember. Be pragmatic. Be consistent Be complete. Be fast. Wednesday,

    29 February, 12

68. Thank you. twitter.com/ runel [email protected] Wednesday, 29 February, 12