Your SlideShare is downloading. ×
  • Like
Mobile API Design Techniques
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Mobile API Design Techniques

  • 408 views
Published

 

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
408
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
13
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Mobile API Design & Techniques. Fred Brunel CTOWednesday, 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 CompleteWednesday, 29 February, 12
  • 18. Simple SOAP WS-* Standard Complete XML-RPC Pure RESTWednesday, 29 February, 12
  • 19. Simple CompleteWednesday, 29 February, 12
  • 20. Trust the OSI model. Works everywhere. And it’s plenty enough. http://en.wikipedia.org/wiki/OSI_modelWednesday, 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/updateWednesday, 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. Facade App Database API Data Display Raw Data RepresentationWednesday, 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 dataWednesday, 29 February, 12
  • 36. 1. Think screens 2.Entities to display 3.Design entity models 4.Design servicesWednesday, 29 February, 12
  • 37. Wednesday, 29 February, 12
  • 38. ID Title Town Country Rating Thumbnail URL Geocode Website Email DescriptionWednesday, 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" }] } BADWednesday, 29 February, 12
  • 43. "book": { "name": "Steve Jobs", "author": "Walter Isaacson", "lenders" = [{ "id": 1234, "name": "Fred", "lastname": "Brunel" }] } GOODWednesday, 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/zachpm@google.com/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 ProtocolBuffersWednesday, 29 February, 12
  • 63. a message TAG LENGTH VALUE 16 bits 32 bits n bits TLV TLV TLV TLV TLV TLV TLV TLV TLV TLV messages streamingWednesday, 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("jdoe@example.com"); 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/fbrunel fred@wherecloud.comWednesday, 29 February, 12