我正在尝试创建一个REST应用程序，我试图隐藏它以隐藏业务逻辑以免受请求和响应。 我必须提供一些我不知道如何处理的例子。
第一个例子：我有一个购物车，产品 x 不能与产品 y 一起订购。然而，客户决定两者都订购。如何给出正确的错误消息或指导客户不允许这样做。因为不能同时发出错误说＆＃34; x 和 y ＆＃34;好像向我揭露了商业逻辑。
由于我们拥有不同的服务，结构已到位。产品可以重复使用，但订单量不同。例如，我们可以为订购布料时需要不同配置的车辆提供订单。在这两种情况下，您都会拥有产品，这些产品具有名称和价格，因此可以重复使用。这就是为什么车辆和布料不能一起订购而且不应该订购的原因。为了使用户更加友好，将提供一项服务，为特定订单提供可用选项。但应该有一个部分验证它并给出正确的错误。
第二个示例：客户有一个待处理订单，并且在挂单完成时无法创建新订单。这似乎/对我来说是有状态的，应该避免。应如何处理？
更新因此解决第一个问题的问题可能是创建类似 / products？type = vehicle 或 / products / combinations？type的端点=车辆。这用于显示允许的产品/组合，并具有端点 / order ，以将产品放入验证发生的位置。这些端点可以独立存在，但上下文可能来自其他地方。我理解正确吗？
答案 0 :(得分：1)
我认为你的问题与REST本身并不完全相关，但无论如何我都会尝试回答它们。也许，你可以提供更多有关困扰你阅读我的答案的细节。
我不完全确定第一个问题与REST有什么关系，因为我觉得它是关于措辞的。我的问题是：为什么不允许同时订购这两种产品？那么，你不能把它们放到同一个购物篮中吗？这不是真正用户友好的，所以最好的想法是允许它。如果你不能同时改变这两者，我只会灰掉＆＃34;所有与产品X一起不允许的物品（如果已经在购物篮中）。
但是，这更像是一个用户体验问题。也许，您可以在这里详细说明用户可以同时插入两个产品的具体情况，但不允许这样做。
针对您的第二个问题：在大多数在线商店中，您通常拥有一个映射到帐户，会话或Cookie的状态。如果您真的希望在REST中使用无状态API，则可以使用订单ID。这些可以传递给每个请求。当然，订单本身就有一个州。但请求没有。
注意：REST并不意味着什么。您基本上没有每个请求的状态，并且URL中包含所有必要的信息。
也许，这有点帮助。
答案 1 :(得分：1)
正如另一个答案已经指出的那样，这只与REST略有关系，我认为更多的是关于＆＃34;暴露业务逻辑＆＃34;和＃34;无国籍状态＆＃34;。
不希望暴露业务逻辑的第一点：如果某个系统确实需要解释特定错误，那么它只暴露业务逻辑。如果只是＆＃34;只有＆＃34;向用户提供本地化消息时，它不会向系统公开任何逻辑。前端系统不需要知道发生了什么，它只需要显示来自后端系统的消息。
有些情况下，前端系统需要知道，才能引导用户。暴露业务逻辑并不是根本错误，只要它不是隐式暴露的，而是明确地是接口描述的一部分。
关于无状态的第二点：REST定义通信需要无状态。这意味着来自客户端的任何任意请求都应该是没有任何先前消息的上下文（这包括以前的登录，会话等等）。每个请求都是独立的。此不意味着特定资源无法保持自己的状态。事实上后端的购物车确实有状态，这没关系。
或者换句话说：下一个请求可以打到不同的服务器并且仍然可以成功吗？我的意思是没有会话复制，分布式缓存或其他魔术。如果是，则通信是无状态的。如果你需要＆＃34;粘＆＃34;会话或类似的事情，然后不，你不是无国籍的。