More Related Content
Similar to Mobile API Design Techniques
Similar to Mobile API Design Techniques (17)
More from Trieu Nguyen (20)
Mobile API Design Techniques
- 1. Mobile API
Design & Techniques.
Fred Brunel
CTO
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
- 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
- 17. Simple
Standard Complete
Wednesday, 29 February, 12
- 18. Simple
SOAP
WS-*
Standard Complete
XML-RPC 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
- 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
- 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
Representation
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
- 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
- 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
- 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
ProtocolBuffers
Wednesday, 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 streaming
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("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.com
Wednesday, 29 February, 12