The hardest thing with HTTP is to send server-initiated messages to client. There are multiple approaches (websockets, SSE, client polling) but they are not simple.
Also HTTP carries some overhead. It's not significant, something like 50-100 bytes, but it might matter for a lot of tiny messages, I guess.
Another factor is: those intermediate proxies might break your app. They might cache your responses even if you don't want that, so your application will act wierdly. Of course any intermediate proxy might break any protocol...
> The hardest thing with HTTP is to send server-initiated messages to client.
My (weak) understanding here is that in most mobile cases this is intrinsically problematic and is the reason for the plethora of push notification standards. In this case HTTP is more battery friendly as a noisy server can't as easily spam your phone with traffic.
HTTP can't be more mobile friendly, since it's exactly the same TCP connection for iOS, there's nothing special about it. You might design mobile-friendly protocol which would leverage proprietary push messages, but that's HTTP-agnostic as well.
I mean, if you need to spam your phone with traffic, you'll do that. If you're writing whatsapp, you want to deliver messages instantly if user has app opened, so you'll keep TCP connection to the server.
I was referring to the low power optimizations like doze in android, where the OS tries to schedule together many actions so to minimize the time the radio is on. In this case the OS can optimize HTTP connections (if you use the OS's HTTP library) better that a bare TCP. (this does not apply if you handle HTTP internally)
Also HTTP carries some overhead. It's not significant, something like 50-100 bytes, but it might matter for a lot of tiny messages, I guess.
Another factor is: those intermediate proxies might break your app. They might cache your responses even if you don't want that, so your application will act wierdly. Of course any intermediate proxy might break any protocol...