【问题标题】:Use Hypermedia instead after first Level in rest URI?在rest URI的第一级之后使用超媒体?
【发布时间】:2013-10-16 03:58:01
【问题描述】:

我在想你从来没有像这样的 UriTemplates:

http://myapi.com/cage/12/pigs/23 - 给我 12 号笼子里的 23 号猪

我认为标准或 REST API 通常不会附加在 /pigs/23 上。我认为您只需将所有内容都保持在一个级别,因此如果我想要那只猪,它会从猪服务and by sending a request to /pigs/23

换句话说,你永远不会看到这样的 url 进入 RESTful API:

http://myapi.com/cage/12/pigs/23

因为在将其映射到 pigs 服务中的特定方法方面,您将如何处理它?你会从 pigs 服务的 GetByCage(int id, intcageId) 中去掉 12 的cageId 吗?

我认为这会变得过于复杂,因为我可以在给定资源中看到大量此类 BySomething 方法,如果您考虑在 API 中执行此操作的所有资源,这些方法可能会变得不一致或不可维护。

如果我没有错,我相信人们将其保留为 [resource]/[id] - 一个级别意味着您永远不会超出 Uri 中的初始资源或 id,您就停在那里。然后在响应中,您使用超媒体为消费者提供另一个 Uri 以获取其他资源。

所以在http://myapi.com/cage/12/pigs/23 的情况下,它真的不应该是那样。它应该是对 /cage/12 的调用,你会得到那个笼子的表示。然后在笼子 json 对象中,您会看到一个可能类似于 http://myapi.com/pigs/23 的属性并进行另一个调用?那是 2 个调用,可能很重,而不是像上面那样通过将子资源放入 Uri 中以某种方式进行一个调用(pig 是笼子的子资源)。那么您是否将子资源作为超媒体(主资源内的链接)并停在那里,这意味着在 REST API 中您永远不会超出您请求的第一个资源,您不会在 url 本身中列出子资源,而是使用超媒体而是将其嵌入到第一个资源中...对吗?

不知道,但我也发现了这个: http://stateless.co/hal_specification.html

【问题讨论】:

  • 如果您要使用 RESTful 和超媒体,那么 URI 设计应该是最不重要的方面之一 - 因为除了调用者应该开始的几个公开的 URI 之外,所有其他 URI 都由您的响应服务 - 因此无论它们目前是什么,您都可以稍后改变主意并提供不同的服务。如果笼子负责给他们的猪编号,例如两个笼子有一个猪 23,而那些不是同一只猪,那么我认为您显示的第一个 URI 非常好。
  • Uri 是最不重要的,因为现在它只得到一件事,它在每次调用时都被简化为原子资源,所以是的,超媒体是驱动关系等的原因,以及过滤器东西的查询字符串。

标签: rest


【解决方案1】:

没有错

myapi.com/cage/12/pigs/34

如果这在您返回的资源的上下文中是有意义的。如果pig 34 仅在cage 12 的上下文中有意义,并且与cage 09 中的pig 34 不同,则尤其如此,那么这将是正确的方法。如果您的客户想要使用 URL myapi.com/cage/12/pigs 查询将在笼子 12 中的所有猪,这也很有意义,这应该返回该笼子中所有猪的 URL。

通常不要强调在您的服务器上解析 URL 有多么困难,您用于 Web 开发的几乎每种语言都有库来帮助解决这个问题。思考与您的资源表示相关的意义。

【讨论】:

  • 我正在考虑使用超媒体,然后我们甚至不必担心像这样复杂的 url。我们只有第一级的 url,要么是 [resource]/(给我全部)要么是 [resource]/{id},之后我们就不需要任何东西了。
  • 嗯,你必须这样做,它是后端设计的一部分,也是与 REST 相关的可用性。我不担心只是解析,它是方法命名、方法所在的位置(什么控制器或服务)以及更重要的是可伸缩性。使用超媒体是比让你的 url 过于复杂更好的方法。原子资源意味着每个资源只提供简单的 cruds,仅此而已。没有 GetByOtherId 废话。超媒体解决了这个问题,并提供了许多其他好处。
  • 你所说的超媒体是什么意思而不是?使用超媒体不会或不应该影响您的 URL。至于拥有非常短的 URL,如果它适合您的资源层次结构,那很好。在您给出的示例中,尽管这似乎不合适。猪在笼子里,这反映在 URL 中。缩短所有 URL 并不反映这种关系。如果这意味着您在客户端失去语义意义,则不应这样做以使服务器上的代码更容易。
  • 那你不懂超媒体(资源链接)。看这个,它可以让你修剪而不用为你的 REST API 提供这么多复杂的 URL。 youtube.com/watch?feature=player_embedded&v=5WXYw4J4QOU
  • 我明白什么是超媒体。 URL 不应该被硬编码到客户端并且应该在它遍历资源时被发现这一事实并不意味着一旦客户端实际执行此操作,资源层次结构就无关紧要了。例如,如果您的 URL 是 api.com/cages/12 链接到 api.com/pigs/45 当客户端到达猪 45 时,它如何返回到笼子 12?您要么必须告诉客户端记住它之前所在的 URL(如何?),要么将笼子的 URL 嵌入到 pig 资源中。如果 URL 是 api.com/cage/12/pigs/45,则客户端只需向后跟踪 URL。
【解决方案2】:

我已经找到了自己的解决方案。那就是使用超媒体作为管理资源链接(关系)的一种手段,而不是让您的用户处理更长的复杂 URI。

不管怎样,看看这个你就会明白,他说得很好。

https://www.youtube.com/watch?feature=player_embedded&v=5WXYw4J4QOU

【讨论】:

  • 你能解释一下你的意思吗?链接消失,视频不是可以浏览的东西。
猜你喜欢
  • 2012-07-23
  • 2011-10-13
  • 1970-01-01
  • 2014-04-09
  • 2012-03-20
  • 1970-01-01
  • 1970-01-01
  • 2016-09-02
  • 1970-01-01
相关资源
最近更新 更多