【发布时间】: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