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

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

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

为了进一步解释我的意思,请考虑将应用程序/JSON或应用程序/XML传递到客户端应用程序的情况。一旦客户机应用程序进入通用格式并获取特定数据段,您就在客户机和服务器之间创建隐藏耦合。相反,如果您使用媒体格式“application/vnd.mycompany.myformat+xml”,那么您是在显式地定义与客户机的契约。当您更改格式并且可以选择创建“application/vnd.mycompany.myformatV2+xml”时,这具有巨大的优势

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

使用下载的javascript的Web应用程序可以使用“application/xml”,因为合同的细节没有编译到客户端。然而,客户机的行为极为有限,仅限于执行javascript预先编程的任何操作。不幸的是,大多数公共RESTful接口忽略了这一约束,人们构建的客户端与未指定的契约紧密耦合。这就是为什么当Twitter改变其格式时,许多客户端会中断。

REST是一种体系结构样式,而不是数据的表示形式。一般来说,今天的数据是用XML或JSON表示的,这两种格式都经过了战斗测试,可以很容易地支持您所指的大型复杂模型。

在其最基本的形式中,REST只是控制“资源”的HTTP动词。该资源的表示可以是简单的,也可以是复杂的。CRUD和list操作是最直接的。在此上下文中还可以轻松生成其他更复杂的API。

当您试图完成的是发布一个API时,REST感觉不到RESTful,但是,我要指出的是,使用REST哲学开发的API已经非常成功。

根据您的描述,您正在处理数据,无论结构有多复杂,数据都应该很好地遵循REST。REST不禁止发布模式,所以您可能也想考虑一下。