RESTful API关系

Question

假设我们使用两个资源来制作API：Author和Book，在这两个资源中，书籍可以有许多作者，而作者可以有很多书籍。

因此，我们设计REST如下：

/books
/books/:id
/books/:id/authors
/authors
/authors/:id
/authors/:id/books

例如，/books/:id应该用给定的id和各种Authors返回D5吗？还是应该返回给定的Book和各种Authors的ids，然后可以通过对/authors/:id或/authors?ids=1,2,3等的一系列查询来查询？

Answer 1

如果不是api端点，而是web站点上的网页，您将如何安排它们？

如果你猜错了，或者更糟的是你不得不用一种以上的方式去做，你会怎么做？

在大多数情况下，答案是:您将创建更多的文档，并添加额外的链接来帮助人们可靠地找到最适合他们的文档。

想想看:互联网上有多少不同的海明威网页？

网络不是你的领域，它是一个文件管理系统。所有HTTP谓词都应用于文档管理域。URI不映射到域对象--这违反了封装。工作(例如:向域模型发出命令)是管理资源的副作用。换句话说，资源是反腐败层的一部分。您应该期望集成域中的资源比业务域中的业务对象多得多。-- 吉姆·韦伯2011年

REST是将域模型伪装为网站的一种尝试。让网络做你的向导吧。

Answer 2

例如，/ Book /: id是否应该返回带有给定id和不同作者的Book？还是应该用给定的id和不同作者的id返回Book，然后可以通过对/ Authors /:id或/authors?ids=1,2,3的一系列查询来查询这些id和id等等？

长篇短篇小说。取决于。

这取决于您希望客户机**如何使用**、交互和<>发现书籍及其<>相关的资源。Book是否应该为客户提供更多或更少的数据将取决于这些事情。

当API只提供一个客户端时。比方说移动应用或者网络应用，这些应用就像灯塔一样。他们的需求用来指示哪个表示套件更适合他们对UX、可用性、效率等的需求。

当我们为多个客户端开发一个web时，我们必须决定如何让他们都使用API，以及我们希望他们做多少请求来访问所有的数据。还有很多其他的事情。

这件事也很重要。可能还有其他限制因素，例如安全性。任何用户都可以访问作者的数据吗？用户列表和搜索作者可以吗？我们是否允许来宾用户查看资源？是?他们可以看到多少数据？他们能更新资源吗？

@VoinceOfUnreason无缘无故地提出了一个好的观点

REST是将域模型伪装为网站的一种尝试。让网络做你的向导吧。

这更容易用HATEOAS进行概念化

{
   "title":"The Jungle Book",
   "published":1894
   "_link":{
        "self":{ "href": "http://myserver/book/x"},
        "authors":{ "href": "http://myserver/book/x/authors"}
   },
   "_embedded":{
         "authors":[
              {
               "name": "Rudyard Kipling",
               "_links:":{ 
                  "self":{ "href": "http://myserver/author/y"},
                  "books":{ "href": "http://myserver/author/y/books"}
              }
         }
   }
}

本书对/book/x的表示将是页面/book/x.page的内容。客户展示这本书所需的一切都在我们希望的范围内。不是的，可以在_links o embedded resource's links之后获取。换句话说，跟随链接就好像它是一个网页。

当然，我们可以在一个请求中返回所有内容。然而，我们必须首先考虑后果。例如，当我们拥有一个Books集合而不是一个单独的集合时会发生什么。服务器将如何在每本书、页等的负载需求和高度并发性的情况下运行？数据库呢？在这种情况下，它会如何表现？如果我们继续在书中添加更多的信息呢？如果我们想要删除相关的数据呢？从书的表示法中删除数据块或删除链接，什么会更不有害呢？

正如你所看到的，有那么多问题我们不能回答你。这就是为什么我们很难说出你应该做什么。这都取决于你的需要。