Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Wednesday, 29 February, 12

Slide 3

Slide 3 text

Wednesday, 29 February, 12

Slide 4

Slide 4 text

Wednesday, 29 February, 12

Slide 5

Slide 5 text

Why? Wednesday, 29 February, 12

Slide 6

Slide 6 text

Though for CPU power Though for bandwidth Lazy designed. Too close to database. Wednesday, 29 February, 12

Slide 7

Slide 7 text

A mobile device is Low powered Low bandwidth Runs on battery! Wednesday, 29 February, 12

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

We want to keep the best user experience at all time. Nobody wants an unresponsive app. Wednesday, 29 February, 12

Slide 11

Slide 11 text

The features of an API has a huge impact on performances. Wednesday, 29 February, 12

Slide 12

Slide 12 text

An API is a contract that dictates what can or cannot be done (directly). Wednesday, 29 February, 12

Slide 13

Slide 13 text

When the API is too lazy, or incomplete; the burden is put on the mobile app. Wednesday, 29 February, 12

Slide 14

Slide 14 text

Any workaround put a stress on the mobile app to use too much network. Wednesday, 29 February, 12

Slide 15

Slide 15 text

API = User Interface. Should be simple and get the job done. Fast. Wednesday, 29 February, 12

Slide 16

Slide 16 text

Landlord Report. Wednesday, 29 February, 12

Slide 17

Slide 17 text

Simple Standard Complete Wednesday, 29 February, 12

Slide 18

Slide 18 text

Simple Standard Complete SOAP XML-RPC WS-* Pure REST Wednesday, 29 February, 12

Slide 19

Slide 19 text

Simple Complete Wednesday, 29 February, 12

Slide 20

Slide 20 text

Trust the OSI model. Works everywhere. And it’s plenty enough. http://en.wikipedia.org/wiki/OSI_model Wednesday, 29 February, 12

Slide 21

Slide 21 text

REST-ish API + JSON Pure REST is a nice to have but not a goal. Wednesday, 29 February, 12

Slide 22

Slide 22 text

GET/POST + Action + Params is fine. PUT/DELETE are nice to have. Wednesday, 29 February, 12

Slide 23

Slide 23 text

Twitter is also REST-ish POST statuses/create POST statuses/destroy/:id POST statuses/update Wednesday, 29 February, 12

Slide 24

Slide 24 text

REST put an emphasis on actions applied to resources; but the issue is the representation. Wednesday, 29 February, 12

Slide 25

Slide 25 text

Simplify the life of the implementor. Be pragmatic. Wednesday, 29 February, 12

Slide 26

Slide 26 text

When designing your API payloads, pay attention to consistency and completeness. Wednesday, 29 February, 12

Slide 27

Slide 27 text

Consistency means developer know what to expect. Principle of least astonishment. Wednesday, 29 February, 12

Slide 28

Slide 28 text

Completeness means less roundtrips. Wednesday, 29 February, 12

Slide 29

Slide 29 text

HTTP latency on 3G ~ 1 second. Every request count. Wednesday, 29 February, 12

Slide 30

Slide 30 text

API is NOT a CRUD interface to your SQL database. It’s a facade. Wednesday, 29 February, 12

Slide 31

Slide 31 text

Database Facade API App Data Representation Raw Data Display Wednesday, 29 February, 12

Slide 32

Slide 32 text

The facade answer to high-level questions. Think services, not objects and methods. Wednesday, 29 February, 12

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Most of the time, a mobile API will be use to get information to be displayed on a screen. Wednesday, 29 February, 12

Slide 35

Slide 35 text

Reverse Design. Start from the UI Not the data Wednesday, 29 February, 12

Slide 36

Slide 36 text

1. Think screens 2.Entities to display 3.Design entity models 4.Design services Wednesday, 29 February, 12

Slide 37

Slide 37 text

Wednesday, 29 February, 12

Slide 38

Slide 38 text

ID Title Town Country Rating Thumbnail URL Geocode Website Email Description Wednesday, 29 February, 12

Slide 39

Slide 39 text

Then, format the representation to be as efficient as possible. Wednesday, 29 February, 12

Slide 40

Slide 40 text

Each JSON entity should have the same consistent representation. Wednesday, 29 February, 12

Slide 41

Slide 41 text

"person": { "id": 1234, "name": "Fred", "lastname": "Brunel", "company": "WhereCloud" } Wednesday, 29 February, 12

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

"book": { "name": "Steve Jobs", "author": "Walter Isaacson", "lenders" = [{ "id": 1234, "name": "Fred", "lastname": "Brunel" }] } GOOD Wednesday, 29 February, 12

Slide 44

Slide 44 text

... "user_mentions": [{ "id": 22548447, "id_str": "22548447", "screen_name": "rno", "name": "Arnaud Meunier", "indices": [0, 4] ]} ... Wednesday, 29 February, 12

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Don’t make the app connects to 10 3rd- party systems. Aggregate on the backend. Wednesday, 29 February, 12

Slide 50

Slide 50 text

The backend has the power, bandwidth and knowledge. Use it! Wednesday, 29 February, 12

Slide 51

Slide 51 text

Make it fast! Some good techniques to be aware of. Wednesday, 29 February, 12

Slide 52

Slide 52 text

JSON is fast to parse, but still, compress everything. Wednesday, 29 February, 12

Slide 53

Slide 53 text

Use Cache-Control on every response that can be cached. Wednesday, 29 February, 12

Slide 54

Slide 54 text

Partial Responses & Partial Updates Let the client decides what to get/update. Wednesday, 29 February, 12

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

PATCH /myfeed/1/1/ Content-Type: application/xml New title Wednesday, 29 February, 12

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

“If you’re serious about network, you should make your own protocol.” —Fake Alan Kay. Wednesday, 29 February, 12

Slide 60

Slide 60 text

The fabric of the Internet is TCP/IP, not HTTP. Wednesday, 29 February, 12

Slide 61

Slide 61 text

Make your own Binary Protocol. Lot faster than text + compression. Sorry! Wednesday, 29 February, 12

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

So. They are tons of efficient solutions and techniques. Wednesday, 29 February, 12

Slide 67

Slide 67 text

Remember. Be pragmatic. Be consistent Be complete. Be fast. Wednesday, 29 February, 12

Slide 68

Slide 68 text

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