详细的问题是：
我正在构建一个 Android 应用程序，它在后端使用我的 REST API。我需要先构建一个注册和登录 API。用谷歌搜索了一段时间后，我觉得我只能采取两种方法。
- 在注册期间，我使用https并获取用户的凭据；针对用户名（服务器端）将其保存在我的数据库中。在登录期间，我再次使用https，并询问用户的凭据；验证数据库上的散列密码并向他返回一个会话 ID，除非他注销，否则我打算永远不会过期。此外，用户进行的任何其他 API 调用 (GET/POST) 都将附带此会话 ID，以便我可以验证用户。
但是在上述方法中，我被迫对任何 API 调用使用https，否则我很容易受到Man in The Middle Attack 的攻击，即如果有人嗅探我的会话 ID，他可以重建类似的 GET/POST 请求，而我不会不想要。我对上述假设是否正确？
- 第二个选项是遵循Amazon Web Services的路径，我使用公钥/私钥身份验证。当用户注册时，我使用https API 将他/她的凭据保存在数据库中。从那时起，我使用用户的散列密码作为私钥。用户进行的任何进一步的 API 调用都将使用用户的私钥获得请求 URL 的散列 blob。在服务器端，我使用保存的私钥重建哈希。如果哈希匹配，我让用户完成他的任务，否则拒绝。在这个选项中，我只需要为注册 API使用https 。REST 可以继续http。
但这里的缺点是，我被迫将我的注册 API 托管在一个单独的虚拟目录中（我正在使用 IIS，我不确定我是否可以在同一个虚拟目录中托管 http 和 https API）。因此我不得不在一个单独的项目文件中开发注册 API。再次，我对上述假设是否正确？
编辑：我正在使用 ASP.NET MVC4 来构建 Web API。
我不愿意在我的所有 REST API 调用中使用https的原因是我觉得它不是轻量级的并且会创建更多的网络负载，这可能不适合移动应用程序。需要进一步的加密/解密和额外的握手可能会进一步影响手机的电池寿命？还是不重要？
您会建议以上两种方法中的哪一种？
PS：我们到处使用 Https，这是最好的决定。更多关于我的博客。