design-patterns - REST 是否适用于大型 3NF 模型

Question

有许多将 REST 与简单数据模型结合使用的示例。例如，具有 5 个属性的客户和具有 6 个属性的订单集合。但是，我很难针对更复杂的模型使用 REST 进行可视化——您可能会在政府采购、财务、医疗记录管理等领域找到这种模型。是否有将 REST 用作大型 LOB 环境的主要 API 的示例。

也许我对 REST 方法的要求太多了？

Answer 1

我正在构建一个目前拥有 250 多个资源的 REST 接口(interface)。到我完成时，我预计会有超过 1000 个。这是一个 ERP 应用程序，涵盖会计、库存、销售、劳动力成本计算、工程等。

单个资源的大小或复杂性与 REST 没有直接关系，而更多地与媒体类型有关。我选择了定义自己的媒体类型的路线，因为我也在构建客户端，并且界面不是供公众使用的。为您的情况选择最佳媒体类型可能是设计 REST 接口(interface)最困难的部分之一。

不幸的是，大多数人似乎都在选择媒体/类型决定并选择通用应用程序/json 或应用程序/xml，然后在浏览器中使用下载的 javascript 来解释格式。 [1]只要您拥有的唯一客户端是浏览器并且您不希望其他任何人重复使用您的界面，它就可以工作。对我来说，这似乎违背了 REST 的主要目标之一，即由于松散耦合和标准化格式而导致的偶然重用。

为了进一步解释我的意思，请考虑将 application/json 或 application/xml 交付给客户端应用程序的情况。一旦客户端应用程序进入该通用格式并获取特定数据，您就在客户端和服务器之间创建隐藏的耦合。相反，如果您使用媒体格式“application/vnd.mycompany.myformat+xml”，您将明确定义与客户端的契约(Contract)。当您更改格式并且可以选择创建“application/vnd.mycompany.myformatV2+xml”时，这具有巨大的优势

人们认为 REST 是一个松散指定的接口(interface)，但实际上并非如此。 REST 接口(interface)在它返回和期望接收的精确媒体类型中应该非常明确。媒体类型是契约(Contract)。如果您收到 application/xml 并使用客户端代码提取/Customer/Name 您违反了契约(Contract)。

使用下载的 javascript 的 Web 应用程序可以使用“application/xml”，因为契约(Contract)的详细信息没有编译到客户端中。但是，客户端的行为极其受限于执行 javascript 预先编程的任何操作。不幸的是，大多数公共(public) RESTful 接口(interface)忽略了这个约束，人们构建了与未指定合约紧密耦合的客户端。这就是为什么当 Twitter 改变其格式时，许多客户都会崩溃。