Why isn't RSA signing usually used in RESTful

I develop a simple app that doesn't use (at least, at first) any third-party authorization. I want to create a RESTful api to be used by iOS/Android/whatever clients, so I've read a bunch of information about implementation of RESTful APIs. However, the usual ways of implementing them involve sending some sort of secure "token" that is used to sign the requests; this leaves the API vulnerable to man-in-the-middle attack, and recommended way to counter it is to use HTTPS.

However, reading all this left me wondering, why aren't private/public keys signing (like RSA) used for this. That way, the client would generate private and public keys from the password, send the public key on registration and keep the private key on the client, and even if someone got hold of all the communications between the server and client, he still wouldn't be able to impersonate the client.

But I know almost nothing about cryptography and security, so there must be reasons why this method isn't used that I couldn't think of, right?

At the moment there is no scheme exists allowing asymmetric key pair derivation from the password.

Another problem is with public key registration. There is a problem with doing authentication, because anyone can have asymmetric key pair, so some additional information must be provided. Public key certificate could be such information, however, this requires client to be a user of some public key infrastructure. Another option, which is used in practice, is that client public key/certificate is provisioned to the server beforehand.

At the end TLS (HTTPS) is already using asymmetric keys to perform authentication and exchange session keys. Client verifies server's public key certificate (server authentication) and server optionally may do the same for client's public key certificate (client authentication).