Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mobile APIs: Optimizing APIs for Many Devices

11,074 views

Published on

Mobile APIs: Optimizing APIs for Many Devices

  1. 1. Mobile APIs: Optimizing APIs forMany Devices12.15.11 @ 11:05 PSTVOIP or Dial-in (see chat)groups.google.com/group/api-craftGreg Brail Sam Ramji Brian Pagano@gbrail @sramji @brianpagno
  2. 2. Your hosts
  3. 3. @gbrail @sramji @brianpagano
  4. 4. groups.google.com/group/api-craft 4
  5. 5. youtube.com/apigee 5
  6. 6. Mobile APIs: Optimizing APIs forMany Devices
  7. 7. Devices are slowParsing XML is (usually) insignificant on servers today.Not so on a phone!(Yes, I realize that devices are getting faster)
  8. 8. Networks are slowTheoretically they are fastOnce you start walking /driving /cycling / skydiving around thatchanges
  9. 9. Programmers are in a hurryXML? What’s that?Forget about SOAP and SAML
  10. 10. Public APIs are inconsistentTwitter can respond in one second or five That adds to your user experience Lots of APIs are lots slower
  11. 11. Private APIs are slowInternal 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. 12. Most APIs talk too muchMy default Twitter timeline: 45K in JSON, 64K in XMLPrivate APIs are usually worse Designed for internal systems and fast networks We have seen 5K, 36K, 100K and up
  13. 13. App DevelopersNone of this is good for you
  14. 14. The API TeamIf you can’t make the API friendlier to app developers, …the developers will take matters into their own hands
  15. 15. Tools in your arsenalData transformation and maskingCompressionCachingDistribution These work for both the app developers and the API team
  16. 16. Data transformation and masking
  17. 17. Convert XML to JSON
  18. 18. Offer a “mobile version” via parameters …returns fewer data fields
  19. 19. Implement a “partial response” architecture …select fewer elements via parameters
  20. 20. Be ruthless! …can always offer the “full data set” via another API
  21. 21. Compression
  22. 22. Built in to the HTTP protocol
  23. 23. Supported by most clients
  24. 24. Not enabled by many servers – why not?
  25. 25. My Twitter timeline: 45K JSON  gzip  6K 64K XML  gzip  6.5K
  26. 26. Caching
  27. 27. Cache complete API responses …in addition to your app server / database cache
  28. 28. A good Pragmatic REST URL structure makes this easier
  29. 29. Distribution
  30. 30. Put caches of API responses all over Use a CDN if you can Return links to it if you can’t
  31. 31. TakeawaysMobile clients are different than serversJavaScript apps are different than serversSo don’t forget that when you implement your API!
  32. 32. THANK YOUQuestions and ideas to:@gbrail@sramji@brianpaganogroups.google.com/group/api-craft

×