I'm currently writing a server-client secure architecture, an alternative to using HTTPS APIs that should work particularly well with mobile apps.
You acquire apps from a store (a trustworthy source) so you can assume that data hasn't been tampered with. Hence you can include with the app files a server certificate and a fallback certificate, and you can use that to securely authenticate with the server.
I'm trying to keep the overhead far lower than TLS (currently, for session resumption only ~210 bytes need to be exchanged for a functional connection), and alleviate the financial burden of TLS certificates (you pay the cost of secure delivery to the store, anyway). RESTful APIs should be pretty straightforward to translate to this model.
Apps today use HTTPS for secure calls to the API, and I think it's highly unnecessary to have the overhead of certificate presentation, cipher negotiation, and even the HTTP header for what is often as few as 40 bytes of request/response data.
Currently the server seems to perform extraordinarily well: I'm running a PHP backend and have a request-response model, like HTTP does, and I'm working on optimizing it to the levels of lighttpd, because I know it's possible. My point is that a reasonably secure specialized protocol can be made more efficient than TLS, especially when you know what you are always connecting to.
You acquire apps from a store (a trustworthy source) so you can assume that data hasn't been tampered with. Hence you can include with the app files a server certificate and a fallback certificate, and you can use that to securely authenticate with the server.
I'm trying to keep the overhead far lower than TLS (currently, for session resumption only ~210 bytes need to be exchanged for a functional connection), and alleviate the financial burden of TLS certificates (you pay the cost of secure delivery to the store, anyway). RESTful APIs should be pretty straightforward to translate to this model.
Apps today use HTTPS for secure calls to the API, and I think it's highly unnecessary to have the overhead of certificate presentation, cipher negotiation, and even the HTTP header for what is often as few as 40 bytes of request/response data.
Currently the server seems to perform extraordinarily well: I'm running a PHP backend and have a request-response model, like HTTP does, and I'm working on optimizing it to the levels of lighttpd, because I know it's possible. My point is that a reasonably secure specialized protocol can be made more efficient than TLS, especially when you know what you are always connecting to.