This document discusses optimizing APIs for mobile devices. It notes that mobile devices and networks are slower than servers, so APIs need to be optimized for these constraints. It recommends transforming data to more efficient formats like JSON, offering partial responses, enabling compression, implementing caching across a content delivery network, and being judicious about the amount of data returned to improve performance for mobile clients. The overall message is that APIs need to be designed with the limitations of mobile in mind.

1. Mobile APIs: Optimizing APIs for
Many Devices
12.15.11 @ 11:05 PST
VOIP or Dial-in (see chat)
groups.google.com/group/api-craft
Greg Brail Sam Ramji Brian Pagano
@gbrail @sramji @brianpagno

2. Your hosts

3. @gbrail @sramji @brianpagano

4. groups.google.com/group/api-craft
4

5. youtube.com/apigee
5

6. Mobile APIs: Optimizing APIs for
Many Devices

7. Devices are slow
Parsing XML is (usually) insignificant on servers today.
Not so on a phone!
(Yes, I realize that devices are getting faster)

8. Networks are slow
Theoretically they are fast
Once you start walking /driving /cycling / skydiving around that
changes

9. Programmers are in a hurry
XML? What’s that?
Forget about SOAP and SAML

10. Public APIs are inconsistent
Twitter can respond in one second or five
That adds to your user experience
Lots of APIs are lots slower

11. Private APIs are slow
Internal systems were designed for a few servers.
Now we throw a few thousand mobile devices at them.
We have seen response times like:
500 milliseconds
5 seconds
30 seconds…

12. Most APIs talk too much
My default Twitter timeline:
45K in JSON, 64K in XML
Private APIs are usually worse
Designed for internal systems and fast networks
We have seen 5K, 36K, 100K and up

13. App Developers
None of this is good for you

14. The API Team
If you can’t make the API friendlier to app developers,
…the developers will take matters into their own hands

15. Tools in your arsenal
Data transformation and masking
Compression
Caching
Distribution
These work for both the app developers and the API team

16. Data transformation and masking

17. Convert XML to JSON

18. Offer a “mobile version” via parameters
…returns fewer data fields

19. Implement a “partial response” architecture
…select fewer elements via parameters

20. Be ruthless!
…can always offer the “full data set” via another API

21. Compression

22. Built in to the HTTP protocol

23. Supported by most clients

24. Not enabled by many servers – why not?

25. My Twitter timeline:
45K JSON  gzip  6K
64K XML  gzip  6.5K

26. Caching

27. Cache complete API responses
…in addition to your app server / database cache

28. A good Pragmatic REST URL structure makes this easier

29. Distribution

30. Put caches of API responses all over
Use a CDN if you can
Return links to it if you can’t

31. Takeaways
Mobile clients are different than servers
JavaScript apps are different than servers
So don’t forget that when you implement your API!

32. THANK YOU
Questions and ideas to:
@gbrail
@sramji
@brianpagano
groups.google.com/group/api-craft