[hobohacker]

Why do you assert it has no benefit for mobile APIs? Here are a few that I can think of off the top of my head:

* SPDY Multiplexing is superior to HTTP pipelining. Pipelining requires in-order responses, which leads to head of line blocking.

* SPDY header compression is a win for mobile, since mobile uplink bandwidth is often a bottleneck. Request header compression allows for fitting more requests into fewer packets.

* Mobile connections are more likely to hang, so using SPDY PINGs (https://insouciant.org/tech/connection-management-in-chromiu...) will help fail fast.

* Multiplexing more requests over fewer connections will help with mobile power usage (https://insouciant.org/tech/connection-management-in-chromiu...).

[dsl]

Because SPDY is designed for quickly loading websites with lots of resources (the average page has 50-100 components). Just because it is new and fancy and from Google doesn't mean you should use it for other things that transport over HTTP/S.

If you are going to dedicate resources to switching to SPDY, you should instead investigate protobuf.

* Almost all APIs are transactional. Your API should be returning all the data you need to render a single screen in your mobile app, or it is inefficient.

* You should be stripping all request headers except for User-Agent, and the server should be responding based on the known capabilities of the app version.

* Pings are not the correct way to deal with hangs. I don't want to spill any secret sauce here, but it should be obvious to anyone with low level TCP experience.

* Pipelining also uses a single connection. Opportunistic FINs are not unique to SPDY.

[hobohacker]

I'm not going to argue whether or not other libraries/protocols (e.g. your example of protobufs) may provide higher value. I was simply questioning your assertion "SPDY has no benefit for mobile APIs."

That said, I've got some comments on your new points:

* "Almost all APIs are transactional. Your API should be returning all the data you need to render a single screen in your mobile app, or it is inefficient." - Addressing this completely would take awhile, and there's no good point in our discussing this exhaustively. I'll simply note that while an API response may return all data necessary to render a single screen in the app, it does seem nice to allow for prioritized out of order responses like SPDY does. There does not seem to be a good reason to have head of line blocking in the responses, since the app should be able to render incrementally.

* "Pings are not the correct way to deal with hangs. I don't want to spill any secret sauce here, but it should be obvious to anyone with low level TCP experience." - I think you must be misunderstanding this, or it must not be obvious Google's TCP team, since they agree with the usage of SPDY PINGs. Perhaps you think SPDY PINGs are a keep-alive mechanism? Note that the article I linked to identifies them as a liveness detection mechanism.

* "Pipelining also uses a single connection. Opportunistic FINs are not unique to SPDY." - I don't know why you bring up pipelining again when I've pointed out that multiplexing is superior. Why put up with response head of line blocking? And I don't know what you're exactly referring to with opportunistic FINs, perhaps you can explain in further detail?

And I'll throw in extra data points. Despite the fact that you don't feel like it's useful for mobile APIs, other non-Google parties clearly do:

Square (https://github.com/square/okhttp has their Android SPDY implementation)

Twitter (https://github.com/jpinner has their SPDY developer's work on Netty, which they use in their mobile APIs)