0

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

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

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

换句话说，你永远不会在 RESTful API 中看到这样的 url：

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

因为在将其映射到猪服务中的特定方法方面，您将如何处理它？你会从 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

4

2 回答 2

2

没有错

myapi.com/cage/12/pigs/34

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

Generally don't stress about how difficult a URL will be to parse on your server, pretty much every language you would be using for web development has libraries to help with this. Think what makes sense in relation to your resource representations.

于 2013-10-16T08:07:29.823 回答
0

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

无论如何，看看这个，你就会明白，他说得很好。

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

于 2013-10-16T19:51:22.480 回答