Mobile API
Design & Techniques.
Fred Brunel
CTO
Why?
Though for CPU power
Though for bandwidth
Lazy designed.
Too close to database.
A mobile device is
Low powered
Low bandwidth
Runs on battery!
A the network is the
weak link.
Network conditions
change in real-time.
We want to keep the
best user experience
at all time.
Nobody wants an
unresponsive app.
The features of an
API has a huge
impact on
performances.
An API is a contract
that dictates what
can or cannot be
done (directly).
When the API is too
lazy, or incomplete;
the burden is put on
the mobile app.
Any workaround put
a stress on the
mobile app to use
too much network.
API = User Interface.
Should be simple and
get the job done. Fast.
Landlord Report.
Simple
Standard Complete
Simple
Standard Complete
SOAP
XML-RPC
WS-*
Pure REST
Simple
Complete
Trust the OSI model.
Works everywhere.
And it’s plenty enough.
http://en.wikipedia.org/wiki/OSI_model
REST-ish API + JSON
Pure REST is a nice to
have but not a goal.
GET/POST + Action +
Params is fine.
PUT/DELETE are nice
to have.
Twitter is also REST-ish
POST statuses/create
POST statuses/destroy/:id
POST statuses/update
REST put an emphasis
on actions applied to
resources; but the
issue is the
representation.
Simplify the life of the
implementor.
Be pragmatic.
When designing your
API payloads, pay
attention to
consistency and
completeness.
Consistency means
developer know what
to expect.
Principle of least
astonishment.
Completeness means
less roundtrips.
HTTP latency on 3G
~ 1 second.
Every request count.
API is NOT a CRUD
interface to your SQL
database.
It’s a facade.
Database
Facade
API
App
Data
Representation
Raw DataDisplay
The facade answer to
high-level questions.
Think services, not
objects and methods.
So, how do we start
from here?
Most of the time, a
mobile API will be use
to get information to
be displayed on a
screen.
Reverse Design.
Start from the UI
Not the data
1. Think screens
2.Entities to display
3.Design entity models
4.Design services
ID
Title
Town
Country
Rating
Thumbnail URL
Geocode
Website
Email
Description
Then, format the
representation to be as
efficient as possible.
Each JSON entity should
have the same consistent
representation.
Be coherent!
"person": {
"id": 1234,
"name": "Fred",
"lastname": "Brunel",
"company": "WhereCloud"
}
"book": {
"name": "Steve Jobs",
"author": "Walter Isaacson",
"lenders" = [{
"person_id": 1234,
"person_name": "Fred",
"per...
"book": {
"name": "Steve Jobs",
"author": "Walter Isaacson",
"lenders" = [{
"id": 1234,
"name": "Fred",
"lastname": "Brune...
...
"user_mentions": [{
"id": 22548447,
"id_str": "22548447",
"screen_name": "rno",
"name": "Arnaud Meunier",
"indices": [...
Pick the right granularity.
Denormalize!
"result": {
...
"categories" = [{ "id": 2 }],
"images": [{ "id": 317171 }],
"tags": [{ "id": 555 }]
...
}
"result": {
...
"categories": [{
"id": 2
"name" = "food"
}],
"images" = [{
"id": 317171
"url": "http://image.com/a.png"
}]...
Denormalize the most
common fields.
Avoid unnecessary
roundtrips.
Don’t make the app
connects to 10 3rd-
party systems.
Aggregate on the
backend.
The backend has the
power, bandwidth
and knowledge.
Use it!
Make it fast!
Some good techniques
to be aware of.
JSON is fast to parse,
but still, compress
everything.
Use Cache-Control on
every response that
can be cached.
Partial Responses &
Partial Updates
Let the client decides
what to get/update.
GET
http://www.google.com/calendar/
feeds/zachpm@google.com/private/
full?fields=entry(title,gd:when)
PATCH /myfeed/1/1/
Content-Type: application/xml
<entry
xmlns='http://www.w3.org/2005/Atom'
xmlns:gd='http://schemas.googl...
Batch Requests
Send multiple
operations, get one
answer.
Persistent
Connections.
Keep a connection
nailed up.
“If you’re serious
about network, you
should make your
own protocol.”
—Fake Alan Kay.
The fabric of the
Internet is TCP/IP, not
HTTP.
Make your own
Binary Protocol.
Lot faster than text +
compression. Sorry!
Message-based API
Custom TLV
MessagePack
ProtocolBuffers
TAG LENGTH VALUE
32 bits16 bits n bits
TLV TLV TLV TLV TLV
TLV TLV TLV TLV TLV
messages streaming
a message
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
...
Person person;
person.set_name("John Doe");
person.set_id(1234);
person.set_email("jdoe@example.com");
fstream output("myf...
So.
They are tons of
efficient solutions
and techniques.
Remember.
Be pragmatic.
Be consistent
Be complete.
Be fast.
Thank you.
twitter.com/fbrunel
fred@wherecloud.com
Mobile API: Design & Techniques
Upcoming SlideShare
Loading in...5
×

Mobile API: Design & Techniques

1,550

Published on

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.

Published in: Technology

Mobile API: Design & Techniques

  1. 1. Mobile API Design & Techniques. Fred Brunel CTO
  2. 2. Why?
  3. 3. Though for CPU power Though for bandwidth Lazy designed. Too close to database.
  4. 4. A mobile device is Low powered Low bandwidth Runs on battery!
  5. 5. A the network is the weak link.
  6. 6. Network conditions change in real-time.
  7. 7. We want to keep the best user experience at all time. Nobody wants an unresponsive app.
  8. 8. The features of an API has a huge impact on performances.
  9. 9. An API is a contract that dictates what can or cannot be done (directly).
  10. 10. When the API is too lazy, or incomplete; the burden is put on the mobile app.
  11. 11. Any workaround put a stress on the mobile app to use too much network.
  12. 12. API = User Interface. Should be simple and get the job done. Fast.
  13. 13. Landlord Report.
  14. 14. Simple Standard Complete
  15. 15. Simple Standard Complete SOAP XML-RPC WS-* Pure REST
  16. 16. Simple Complete
  17. 17. Trust the OSI model. Works everywhere. And it’s plenty enough. http://en.wikipedia.org/wiki/OSI_model
  18. 18. REST-ish API + JSON Pure REST is a nice to have but not a goal.
  19. 19. GET/POST + Action + Params is fine. PUT/DELETE are nice to have.
  20. 20. Twitter is also REST-ish POST statuses/create POST statuses/destroy/:id POST statuses/update
  21. 21. REST put an emphasis on actions applied to resources; but the issue is the representation.
  22. 22. Simplify the life of the implementor. Be pragmatic.
  23. 23. When designing your API payloads, pay attention to consistency and completeness.
  24. 24. Consistency means developer know what to expect. Principle of least astonishment.
  25. 25. Completeness means less roundtrips.
  26. 26. HTTP latency on 3G ~ 1 second. Every request count.
  27. 27. API is NOT a CRUD interface to your SQL database. It’s a facade.
  28. 28. Database Facade API App Data Representation Raw DataDisplay
  29. 29. The facade answer to high-level questions. Think services, not objects and methods.
  30. 30. So, how do we start from here?
  31. 31. Most of the time, a mobile API will be use to get information to be displayed on a screen.
  32. 32. Reverse Design. Start from the UI Not the data
  33. 33. 1. Think screens 2.Entities to display 3.Design entity models 4.Design services
  34. 34. ID Title Town Country Rating Thumbnail URL Geocode Website Email Description
  35. 35. Then, format the representation to be as efficient as possible.
  36. 36. Each JSON entity should have the same consistent representation. Be coherent!
  37. 37. "person": { "id": 1234, "name": "Fred", "lastname": "Brunel", "company": "WhereCloud" }
  38. 38. "book": { "name": "Steve Jobs", "author": "Walter Isaacson", "lenders" = [{ "person_id": 1234, "person_name": "Fred", "person_lastname": "Brunel" }] } BAD
  39. 39. "book": { "name": "Steve Jobs", "author": "Walter Isaacson", "lenders" = [{ "id": 1234, "name": "Fred", "lastname": "Brunel" }] } GOOD
  40. 40. ... "user_mentions": [{ "id": 22548447, "id_str": "22548447", "screen_name": "rno", "name": "Arnaud Meunier", "indices": [0, 4] ]} ...
  41. 41. Pick the right granularity. Denormalize!
  42. 42. "result": { ... "categories" = [{ "id": 2 }], "images": [{ "id": 317171 }], "tags": [{ "id": 555 }] ... }
  43. 43. "result": { ... "categories": [{ "id": 2 "name" = "food" }], "images" = [{ "id": 317171 "url": "http://image.com/a.png" }], ... }
  44. 44. Denormalize the most common fields. Avoid unnecessary roundtrips.
  45. 45. Don’t make the app connects to 10 3rd- party systems. Aggregate on the backend.
  46. 46. The backend has the power, bandwidth and knowledge. Use it!
  47. 47. Make it fast! Some good techniques to be aware of.
  48. 48. JSON is fast to parse, but still, compress everything.
  49. 49. Use Cache-Control on every response that can be cached.
  50. 50. Partial Responses & Partial Updates Let the client decides what to get/update.
  51. 51. GET http://www.google.com/calendar/ feeds/zachpm@google.com/private/ full?fields=entry(title,gd:when)
  52. 52. 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>
  53. 53. Batch Requests Send multiple operations, get one answer.
  54. 54. Persistent Connections. Keep a connection nailed up.
  55. 55. “If you’re serious about network, you should make your own protocol.” —Fake Alan Kay.
  56. 56. The fabric of the Internet is TCP/IP, not HTTP.
  57. 57. Make your own Binary Protocol. Lot faster than text + compression. Sorry!
  58. 58. Message-based API Custom TLV MessagePack ProtocolBuffers
  59. 59. TAG LENGTH VALUE 32 bits16 bits n bits TLV TLV TLV TLV TLV TLV TLV TLV TLV TLV messages streaming a message
  60. 60. 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; }
  61. 61. 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;
  62. 62. So. They are tons of efficient solutions and techniques.
  63. 63. Remember. Be pragmatic. Be consistent Be complete. Be fast.
  64. 64. Thank you. twitter.com/fbrunel fred@wherecloud.com
  1. Gostou de algum slide específico?

    Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

×