REST返回一个对象图

Question

我是REST架构设计的新手,但我认为我已经涵盖了它的基础知识.

从RESTful调用返回对象时遇到问题.如果我发出请求,例如http:// localhost / {type A}/{id},我将从具有指定id的数据库返回A的实例.

我的问题是当A包含B对象的集合时会发生什么？目前,我生成的XML返回A,其中包含B对象的集合.可以想象,如果B类型具有C对象的集合,那么返回的XML将最终成为一个非常复杂的对象图.

我不能100%肯定,但这感觉违反了RESTful原则,XML for A应该返回A的字段等以及它所拥有的B集合的URI集合.

对不起,如果这有点令人困惑,我可以尝试详细说明.这似乎是一个相对基本的问题,但我无法确定哪种方法更"REST".

干杯,

Aidos

Answer 1

一个重要的RESTful原则是一切都有URI.

你有这样的URI.

• / A /和/ A/id /获取A和特定A的列表.A响应包括B的ID.
• / B /和/ B/id /获取B和特定B的列表.B响应包括C的ID.
• / C /和/ C/id /获取C和特定C的列表.

您可以通过一系列查询重建ABC结构.你得到A,然后得到相关的B. 获得B时,您将获得所引用的各种C.

编辑

没有什么能阻止你多回来.

例如,您可能具有以下类型的URI.

• /flat/A/id/,/flat/B/id/并/flat/C/id/返回"平坦"(即无深度)结构.

• /deep/A/id/,/deep/B/id/并/deep/C/id/返回完整深度的结构.

这/deep/A/id/将是整个结构,在一个大的嵌套XML文档中.对于可以处理它的客户来说很好. /flat/A/id/将只是平面文档中的顶级.最适合无法处理深度的客户.

Answer 2

没有任何迹象表明您的REST界面不能是关系型的.

1. / bookstore/{bookstoreID}
2. / bookstore/{bookstoreID}/books
3. / book/{bookID}

基本上,您与数据库架构的对应关系是1:1.

除了形成儿童名单的多对多关系.例如,/ bookstore/657/books应返回书籍ID或URL列表.然后,如果您想要特定书籍的数据,您可以调用第3个URL.

这只是我的头脑,请讨论优点.

Answer 3

创造一个平坦的宇宙，并将其暴露给世界。

即使当我使用 SOAP（它可以轻松处理任意深度的分层对象图）时，我也会展平该图并使用简单 ID 链接所有内容（您甚至可以使用数据库 ID，尽管想法是您希望您不想向全世界公开你的 PK）。

应用程序内的对象世界不一定与您向世界公开的对象世界相同。让 A 有孩子，让 B 有孩子，但无需在 REST 请求 URL 中反映这一点。

为什么要压扁？因为这样你就可以做一些事情，比如稍后通过 ID 获取对象，或者批量发送它们（或多或少都是相同的情况）...比这更好的是，当对象层次结构发生变化时，请求 URI 不会改变（对象 37252 始终相同，即使它已被重新分类）。

编辑：嗯，你要求它......这是我最终使用的架构： package: server - 包含在前端服务器和后端服务器之间共享的超类

package: frontEndServer - 包含前端服务器必须遵守的服务器接口。该界面很好，因为如果您决定从 SOAP 更改为直接的 Web 客户端（也使用 JSON 或其他格式），那么您就已经完成了所有界面的布局。它还包含将扔给客户端的前端类的所有实现，以及类之间交互的所有逻辑（除了如何与客户端对话）。

package: backEndServer - 包含后端服务器将遵循的服务器接口。服务器实现的一个示例是与 MySql DB 对话的服务器实现或与 XML DB 对话的服务器实现，但服务器接口是中立的。该包还包含服务器接口的实现用于完成工作的所有类，以及后端的所有逻辑（持久性除外）。

然后你就有了每一个的实现包......其中包括诸如如何持久保留后端以及如何与前端客户端对话之类的内容。例如，前端实现包可能知道用户已登录，而 frontEndServer 只知道它必须实现创建用户和登录的方法。

在开始写这篇文章后，我意识到描述所有内容可能需要更多时间，但这里您已经掌握了要点。