mobile apis: optimizing apis for many devices
TRANSCRIPT
Mobile APIs: Optimizing APIs for Many Devices
12.15.11 @ 11:05 PSTVOIP or Dial-in (see chat)
Greg Brail Sam Ramji Brian Pagano
@gbrail @sramji @brianpagno
groups.google.com/group/api-craft
Your hosts
@sramji@gbrail @brianpagano
4
groups.google.com/group/api-craft
5
youtube.com/apigee
Mobile APIs: Optimizing APIs for Many Devices
Devices are slow
Parsing XML is (usually) insignificant on servers today.Not so on a phone!
(Yes, I realize that devices are getting faster)
Networks are slow
Theoretically they are fast
Once you start walking /driving /cycling / skydiving around that changes
Programmers are in a hurry
XML? What’s that?
Forget about SOAP and SAML
Public APIs are inconsistent
Twitter can respond in one second or five
That adds to your user experienceLots of APIs are lots slower
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 milliseconds5 seconds30 seconds…
Most APIs talk too much
My default Twitter timeline:45K in JSON, 64K in XML
Private APIs are usually worseDesigned for internal systems and fast networksWe have seen 5K, 36K, 100K and up
App Developers
None of this is good for you
The API Team
If you can’t make the API friendlier to app developers,
…the developers will take matters into their own hands
Tools in your arsenal
Data 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
Takeaways
Mobile clients are different than servers
JavaScript apps are different than servers
So don’t forget that when you implement your API!
THANK YOUQuestions and ideas to:
@gbrail@sramji@brianpagano
groups.google.com/group/api-craft