Mobile APIs: Optimizing APIs for Many Devices

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

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 getting faster)

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 are lots slower

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…

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

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 hands

Tools in your arsenalData transformation and maskingCompressionCachingDistribution These work for both the app developers and the API team

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 implement your API!

THANK YOUQuestions and ideas to:@gbrail@sramji@brianpaganogroups.google.com/group/api-craft

http://blog.apigee.com	6245
http://apigee.com	101
http://feeds.apigee.com	14
http://mktg-dev.wearepropeople.md	6
http://blog.sonoasystems.com	6
http://translate.googleusercontent.com	1
http://feeds.feedburner.com	1
http://www.newsblur.com	1
http://webcache.googleusercontent.com	1
http://blog.edit.apigee.net	1
http://edit.mktg.jupiter.apigee.net	1
http://mktg.jupiter.apigee.net	1
http://www.linkedin.com	1

Mobile APIs: Optimizing APIs for Many Devices

by Apigee

Accessibility

Categories

Upload Details

Usage Rights

13 Embeds 6,380

Statistics

Mobile APIs: Optimizing APIs for Many Devices Presentation Transcript