Mobile APIs: Optimizing APIs forMany Devices12.15.11 @ 11:05 PSTVOIP or Dial-in (see chat)groups.google.com/group/api-craf...
Your hosts
@gbrail   @sramji   @brianpagano
groups.google.com/group/api-craft                                    4
youtube.com/apigee                     5
Mobile APIs: Optimizing APIs forMany Devices
Devices are slowParsing XML is (usually) insignificant on servers today.Not so on a phone!(Yes, I realize that devices are...
Networks are slowTheoretically they are fastOnce you start walking /driving /cycling / skydiving around thatchanges
Programmers are in a hurryXML? What’s that?Forget about SOAP and SAML
Public APIs are inconsistentTwitter can respond in one second or five   That adds to your user experience   Lots of APIs a...
Private APIs are slowInternal systems were designed for a few servers.Now we throw a few thousand mobile devices at them.W...
Most APIs talk too muchMy default Twitter timeline:   45K in JSON, 64K in XMLPrivate APIs are usually worse    Designed fo...
App DevelopersNone of this is good for you
The API TeamIf you can’t make the API friendlier to app developers,       …the developers will take matters into their own...
Tools in your arsenalData transformation and maskingCompressionCachingDistribution      These work for both the app develo...
Data transformation and masking
Convert XML to JSON
Offer a “mobile version” via parameters       …returns fewer data fields
Implement a “partial response” architecture       …select fewer elements via parameters
Be ruthless!       …can always offer the “full data set” via another API
Compression
Built in to the HTTP protocol
Supported by most clients
Not enabled by many servers – why not?
My Twitter timeline:       45K JSON  gzip  6K       64K XML  gzip  6.5K
Caching
Cache complete API responses   …in addition to your app server / database cache
A good Pragmatic REST URL structure makes this easier
Distribution
Put caches of API responses all over       Use a CDN if you can       Return links to it if you can’t
TakeawaysMobile clients are different than serversJavaScript apps are different than serversSo don’t forget that when you ...
THANK YOUQuestions and ideas to:@gbrail@sramji@brianpaganogroups.google.com/group/api-craft
Upcoming SlideShare
Loading in...5
×

Mobile APIs: Optimizing APIs for Many Devices

9,641

Published on

3 Comments
5 Likes
Statistics
Notes
  • <br /><iframe width="350" height="288" src="http://www.youtube.com/embed/79zkHPog2gQ" frameborder="0" allowfullscreen></iframe>
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • <br /><iframe width="350" height="288" src="http://www.youtube.com/embed/aHwfbJeMmeQ" frameborder="0" allowfullscreen></iframe>
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • I've missed webinar yesterday, is there a video of talk?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
9,641
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
89
Comments
3
Likes
5
Embeds 0
No embeds

No notes for slide
  • Creative Commons Attribution-Share Alike 3.0 United States License
  • Creative Commons Attribution-Share Alike 3.0 United States License
  • 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

    ×