java - 可扩展、安全且易于使用的 Web 服务有哪些特点？

Question

我们的应用程序目前公开使用 WSDL 1.1 和 SOAP 1.1 构建的 Web 服务，遵循以下 w3c 标准:

http://schemas.xmlsoap.org/soap/http is the WSDL 1.1 binding for the SOAP 1.1 HTTP binding.

我们希望改进我们的网络服务，使其可扩展、安全且易于使用

易于使用是指此时 Web 服务不包含该层上的任何业务逻辑。基本上，我们当前的 Web 服务可以看作是为外部/第 3 方开发人员提供的导入/导出服务。

这项工作让我想到了这个问题:

What do I have to expect of a revamp of our web services that are scallable, secure and easy to use?

---

我们网络服务的当前问题

• 您必须登录(第一次交易)才能接收 token (将 session 保存在内存中)才能使用它们。
• 不可扩展，因为任何开发人员都可能打开 20K session 并导致网络服务服务器崩溃。
• 不安全，因为网站管理员的相同用户可以使用网络服务。
• 使用起来并不方便，因为网络服务不包含任何业务逻辑。

我们的客户喜欢我们的网络服务接口(interface)的原因是，他们在网络应用程序中添加的任何数据元素都会立即暴露在网络服务 (wsdl) 定义中。

---

再补充一点:

我希望证实我的理论，即如果我们以 RESTful 方式实现我们的 Web 服务，上述所有问题都可以得到解决。由于每笔交易都不会导致内存堆积，并且每笔交易都将包含带有公钥或类似内容的安全设置。

无论哪种方式，JRO 都是正确的，如果我将问题分成一系列，我可能会得到更好的结果。我会把这个问题留在这里直到今天结束，如果我没有得到更好的结果，我会听取 JRO 的建议。

Answer 1

您要问三个不同的问题，这些问题可能相互关联，但问题太大，以至于您只能得到“视情况而定”的综合答案。如果这是您项目的范围，则将其进一步分割，即更细化。尝试一次解决这个问题。

让我们从您确定的 Web 服务问题来解决这个问题(围绕您的问题的概念对于这个空间来说太大了):

• 您必须登录(第一次交易)才能接收 token :不确定为什么在没有上下文的情况下将其视为“问题”。生成/检查 token 有问题吗？用户的实现是否有问题？您需要澄清为什么这是一个问题。

• 不可扩展，因为任何开发人员都可能打开 20K session 并使网络服务服务器崩溃。HTTP 连接问题最好由网络服务器和负载平衡器处理，而不是程序化管理。如果您需要限制单个端点的连接，请从硬件层开始。

• 不安全，因为站点管理员的相同用户可以使用 Web 服务。这意味着服务的安全实现，以及如何处理凭证周围的逻辑在内部。除了解决这个问题，不知道该说些什么——这是你的逻辑，一旦你掌握了凭据，你就可以控制做什么。如果问题出在安全控制模型上，那就是另一回事了。确定问题的真正症结所在，不要将您的实现与经过验证的模型混淆。

• 它不容易使用，因为 Web 服务不包含任何业务逻辑。 如果不详细说明这意味着什么，它的意义就很小；上下文不够。不过这类题偏向于web服务方法/功能设计。为此，您的方法中的粗粒度是首选 - 使它们更具包容性，而不是更少。

我的建议:咬掉一个单独的部分，例如安全实现，然后首先处理它。尝试同时处理其他部分只会让事情变得更加困惑。