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