REST适用于大型3NF型号

Question

有很多使用REST和简单数据模型的例子。例如，具有5个属性的客户和具有6个属性的订单集合。但是，我很难在一个更复杂的模型上使用REST进行可视化 - 您可以在政府采购，财务，医疗记录管理等中找到这些模型。是否有REST被用作大型LOB环境中的主要API的示例。

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

Answer 1

我正在构建一个目前拥有超过250个资源的REST接口。当我完成时，我希望有超过1000个。这是一个ERP应用程序，涵盖会计，库存，销售，人工成本，工程等。

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

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

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

人们认为REST是一个松散指定的界面，但实际上并非如此。 REST接口应该在它返回并期望接收的精确媒体类型中非常明确。媒体类型是合同。如果您收到application / xml并使用客户端代码提取/客户/名称，那么您将违反合同。

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

Answer 2

REST是一种架构风格，而不是数据的表示。一般来说，今天的数据用XML或JSON表示，经过实战测试，可以轻松支持您所指的大型复杂模型。

在最基本的形式中，REST只是用于控制“资源”的HTTP动词。该资源的表示可以像您需要的那样简单或复杂。 CRUD和列表操作是最直接的。在此上下文中也可以轻松生成其他更复杂的API。

Answer 3

只要有合理的描述性路径来描述您希望达到的数据，REST就是合适的。

当你想要完成的是发布API时，REST并不觉得RESTful，但是，我会注意到使用REST哲学开发的API非常成功。

根据您的描述，您正在使用数据，这应该非常好地遵循REST，而不管结构有多复杂。 REST不禁止发布模式，因此您可能也想考虑这一点。