REST是否适用于大型3NF模型

Question

在简单的数据模型中使用REST的例子有很多。例如，一个拥有5个属性的客户和一个具有6个属性的订单集合。但是，我很难想象在更复杂的模型上使用REST --您可能会在政府采购、金融、医疗记录管理等领域找到这种模型。是否有将REST用作大型LOB环境的主要API的示例。

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

Answer 1

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

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

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

为了进一步解释我的意思，请考虑将application/json或application/xml交付给客户机应用程序的情况。一旦客户端应用程序采用这种通用格式并提取出特定的数据，您就在客户端和服务器之间创建了隐藏的耦合。如果您使用的是媒体格式"application/vnd.mycompany.myformat+xml“，那么您就是在显式地定义与客户端的契约。当您对格式进行更改并可以选择创建“application/vnd.mycompany.myformat V2+xml”时，这有一个巨大的优势。

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

使用下载的javascript的Web应用程序可以使用"application/xml“，因为合约的细节没有编译到客户端中。但是，客户端的行为仅限于执行javascript已预先编程完成的任何操作。不幸的是，大多数公共RESTful接口都忽略了这一限制，人们构建的客户端与未指定的契约紧密耦合。这就是为什么当Twitter改变它的格式时，许多客户都崩溃了。

Answer 2

REST是一种架构风格，而不是数据的表示。通常，今天的数据是用XML或JSON表示的，这两种格式都经过了实战测试，可以很容易地支持您所指的大型复杂模型。

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

Answer 3

只要有一条合理的描述性路径来描述您希望获取的数据，REST就是合适的。

当你想要发布一个应用程序接口时，REST给人的感觉并不像RESTful，但是，我要指出的是，使用REST理念开发的API已经非常成功了。

从您的描述来看，您正在处理数据，这些数据应该很好地与REST保持一致，无论结构有多复杂。REST并不禁止发布模式，因此您可能也需要考虑这一点。