假设我在前端有一个 RESTful Web 服务和一个商业 Android 应用程序，用于与之交互。我可能会使用 SSL 使端点不可见，但仍然有人可以做一些逆向工程来找到它们。
我也可以改用 SOAP，这样对 Web 服务的调用会稍微复杂一些。但是，我仍然不知道这是否比基于 RESTful 的服务给了我任何真正的优势。
我正在考虑将密钥硬编码到我的客户端应用程序中，以便只有我的客户端应用程序可以使用该服务。此外，也许一些代码混淆可能会有所帮助。但是，这真的有多大帮助？
更新：正如 JOW 指出的提琴手
可用于解密 https 并查看完整请求。但是，如果我只使用 Android 应用程序，这可以通过在 Android 客户端应用程序中硬编码服务器证书来解决。此外，还有 SOAP WS-Security，但我想可以制作一个工具以类似于提琴手的方式来规避它。
这是不可能的。包含使用 API 所需的所有说明对于您的应用程序来说至关重要。任何有足够技能和时间的人都可以提取这些秘密并创建自己的客户。
无论使用 REST 还是 SOAP，创建自己的客户端都非常简单直接，只要您的现有客户端可供 Play 商店中的每个人使用。只需使用Fiddler从 Android 设备捕获 HTTP 流量，然后根据捕获的流量设计您自己的客户端。
甚至 HTTPS 流量也可以使用 Fiddler 轻松解密。HTTP 方法、URL、标头、Cookie、正文和您的密钥都是可见的。我认为这根本不安全。（还有其他反向代理可以做和 Fiddler 一样的事情。）
从安全的角度来看，不，没有办法做到这一点。无论您对代码和协议进行多少混淆，事实是访问 API 的代码和访问 API 时产生的网络流量都掌握在您的用户手中，他们可以使用任何逆向工程工具他们想要就可以了。
从业务的角度来看，如果有人产生替代客户，您需要评估您的成本与额外成本，以实施措施以防止这种情况发生。例如，您可以完全使用高度混淆的专有 API（避免 REST、SOAP 和其他标准化协议），但这对您来说实施起来会更加困难，因此成本也会更高。另一方面，这会使某人进行逆向工程变得更加困难。您需要确定这些措施（或其他适当的措施）对您的业务是否值得。
从法律的角度来看，很多地方都有禁止生产或使用第三方客户端的服务条款。您可以通过监控服务器的流量来确定是否有可能使用第三方客户端，或者通过观察第三方客户端在应用商店中的出现来强制执行此操作。您还可以决定是否有资源采取法律行动，以及您是否值得采取这种行动。
从用户关系的角度来看，您可能需要重新考虑禁止所有第三方客户端作为一揽子规则的想法。显然，没有人希望开发人员通过他们自己的广告制作一个糟糕的客户端，但是现在很多服务都允许第三方开发人员注册他们的应用程序并接收 API 密钥。注册过程可以根据您的需要简单或复杂，从简单的使用条款（例如“不要在应用程序中放置您自己的广告”）到对其界面的评估或对其来源的全面检查代码（当然，越简单，开发人员就越愿意注册）。允许第三方开发者使用你的 API 也不一定是坏事——他们可能想要开发一个使用你的服务作为数据源的应用程序，但不是
从安全意义上讲，您不能使未经授权的 API 访问成为不可能，但您可以将其最小化。这不是一个真正的安全问题，但威胁模型的概念非常合适：您希望阻止谁访问您的 API，以及您希望避免什么样的损害？
许多大型网站禁止以其他方式访问其服务，通常是为了继续投放广告。他们通过在多个层面上采取的综合措施来做到这一点：
这些都不是 100% 有效的，但它们不需要如此。重要的是他们减少了损失。想想你想要完成什么，并相应地选择你的对策。