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

Mobile API. Design & Techniques.

Fred Brunel
February 29, 2012

Mobile API. Design & Techniques.

Designing a web API is hard, designing a mobile API is even harder. With heavy constraints such as bandwidth, latency and CPU power, developing a mobile API is a challenge for the service provider and the application developer. As mobile devices become ubiquitous and connected, offering the best user experience in mobile application is crucial; optimizing the network is an important part of it.

In this talk we'll cover the challenges of designing a mobile API as well as innovative solutions and best practices that can be used by the service provider. We'll share our broad experience in developing connected mobile apps.

Fred Brunel

February 29, 2012
Tweet

More Decks by Fred Brunel

Other Decks in Programming

Transcript

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

    close to database. Wednesday, 29 February, 12
  2. A mobile device is Low powered Low bandwidth Runs on

    battery! Wednesday, 29 February, 12
  3. We want to keep the best user experience at all

    time. Nobody wants an unresponsive app. Wednesday, 29 February, 12
  4. The features of an API has a huge impact on

    performances. Wednesday, 29 February, 12
  5. An API is a contract that dictates what can or

    cannot be done (directly). Wednesday, 29 February, 12
  6. When the API is too lazy, or incomplete; the burden

    is put on the mobile app. Wednesday, 29 February, 12
  7. Any workaround put a stress on the mobile app to

    use too much network. Wednesday, 29 February, 12
  8. API = User Interface. Should be simple and get the

    job done. Fast. Wednesday, 29 February, 12
  9. Trust the OSI model. Works everywhere. And it’s plenty enough.

    http://en.wikipedia.org/wiki/OSI_model Wednesday, 29 February, 12
  10. REST-ish API + JSON Pure REST is a nice to

    have but not a goal. Wednesday, 29 February, 12
  11. GET/POST + Action + Params is fine. PUT/DELETE are nice

    to have. Wednesday, 29 February, 12
  12. REST put an emphasis on actions applied to resources; but

    the issue is the representation. Wednesday, 29 February, 12
  13. API is NOT a CRUD interface to your SQL database.

    It’s a facade. Wednesday, 29 February, 12
  14. Most of the time, a mobile API will be use

    to get information to be displayed on a screen. Wednesday, 29 February, 12
  15. "book": { "name": "Steve Jobs", "author": "Walter Isaacson", "lenders" =

    [{ "person_id": 1234, "person_name": "Fred", "person_lastname": "Brunel" }] } BAD Wednesday, 29 February, 12
  16. "book": { "name": "Steve Jobs", "author": "Walter Isaacson", "lenders" =

    [{ "id": 1234, "name": "Fred", "lastname": "Brunel" }] } GOOD Wednesday, 29 February, 12
  17. ... "user_mentions": [{ "id": 22548447, "id_str": "22548447", "screen_name": "rno", "name":

    "Arnaud Meunier", "indices": [0, 4] ]} ... Wednesday, 29 February, 12
  18. "result": { ... "categories" = [{ "id": 2 }], "images":

    [{ "id": 317171 }], "tags": [{ "id": 555 }] ... } Wednesday, 29 February, 12
  19. "result": { ... "categories": [{ "id": 2 "name" = "food"

    }], "images" = [{ "id": 317171 "url": "http://image.com/a.png" }], ... } Wednesday, 29 February, 12
  20. Don’t make the app connects to 10 3rd- party systems.

    Aggregate on the backend. Wednesday, 29 February, 12
  21. Partial Responses & Partial Updates Let the client decides what

    to get/update. Wednesday, 29 February, 12
  22. “If you’re serious about network, you should make your own

    protocol.” —Fake Alan Kay. Wednesday, 29 February, 12
  23. Make your own Binary Protocol. Lot faster than text +

    compression. Sorry! Wednesday, 29 February, 12
  24. 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
  25. 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
  26. 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