REST适用于大型3NF型号

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

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

我正在构建一个目前拥有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改变其格式时,许多客户都会破产.

REST是一种架构风格,而不是数据的表示.通常,今天的数据以XML或JSON表示,这些数据已经过战斗测试,可以轻松支持您所指的大型复杂模型.

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