In detail here's the problem: 

I'm building an Android app, which consumes my REST API on the back-end. I need to build a Registration and Login API to begin with. After searching with Google for a while, I feel like there are only two approaches that I can take. 


During Registration, I use https and get the user's credentials; save it in my DB against the username(server side). During Login, again I use https, and ask the user's credentials; verify the hashed password on the DB and return him a session ID, which I'm planning to never expire unless he Logs Out. Further any other API calls (GET/POST) that the user makes, will be accompanied with this session ID so that I can verify the user. 


But in the above approach I'm forced to use https for any API call, else I'm vulnerable to Man in The Middle Attack, i.e. if anyone sniffs over my session ID, he can reconstruct similar GET/POST requests which I wouldn't want. Am I right with the above assumption?


The second option is to follow the path of Amazon Web Services, where I use public/private key authentication. When a user registers I use a https API to save his/her credentials in the DB. From then on I use the user's hashed password as the private key. Any further API calls that the user makes will be having a hashed blob of the request URL using the user's private key. On the server side I reconstruct the hash using the saved private key. If the hash is a match I let the user do his task, else reject. In this option I need to use https only for the registration API. The REST can go on on http. 


But here the disadvantage is, that I'm forced to host my Registration API in a separate Virtual Directory (I'm using IIS and I'm not sure if I can host both http and https APIs in the same Virtual Directory). Hence I'm forced to develop the Registration API in a separate project file. Again Am I right with the above assumption? 

Edit: I'm using ASP.NET MVC4 to build the web API.

The reason I'm reluctant to use https for all of my REST API calls is that I feel it's not lightweight and creates more network payload, which may not be best suited for a mobile app. Further encryption/decryption and extra handshake required may further affect a mobile's battery Life? Or is it not significant?

Which of the above two approaches would you suggest?

PS: We went with Https everywhere, and it was the best decision. More of that on my blog.

I'd go with SSL/TLS everywhere (since you control both sides, forcing TLS 1.2 should be feasible). It's relatively simple to use, and you get a lot of security features for free. For example if you don't use SSL, you'll need to worry about replay attacks.

If you're worried about performance, make sure session resumption is supported by both the server and the client. This makes later handshakes much cheaper. Since the handshake is quite expensive in SSL compared to the encryption of the actual data, this reduces overall load considerably.

If you use HTTP 2, you can even send multiple requests over a single connection, that way you avoid the complete TCP and SSL handshake overhead on later requests.
