为头/细节实体关系构建休息端点

Question

鉴于与此类似的对象结构，如何构建API？标题BookWishlists是否有自己的端点，并且WishlistEntries是单独提取的？

此外，API应该如何构成各种类型的WishlistEntries？我们是否有一个端点接受要添加的条目“类型”？（POST / [EntryType] / [BaseBookId]作为示例）为每种类型的条目设置一个不同的端点是否更好？（POST / BookOnAmazon / [ BookOnAmazon：Id]）

指向这样做的api的链接将会受到赞赏，因为我们无法找到它。

我们在ASP.net Web API中使用Phonegap / Javascript前端进行此操作（如果相关）。

Answer 1

每个“资源”都是一个端点，我认为您的愿望清单的URL结构看起来很好。

我认为将数据库表直接映射到资源始终是正确的做法。最好让自己置身于API消费者的心态。他们需要提出什么要求？

在我看来，你只有2个资源

• 心愿
• 书

书籍实际上是愿望清单的一部分。您可能希望也可能不希望通过愿望清单条目返回所有书籍详细信息，或者可能只是消费者可以请求的ID和ID。后者需要消费者更多的开发工作/请求，但可能会更有效。

Answer 2

您可以按照/resources/{particularResourceId}/subresources/{oneSubresourceId}

的标准进行操作

因此，如果您不打算直接访问图书，我会想到只有一个主要资源

/wishlists/获取愿望清单列表 获得一个特定愿望清单/wishlists/{listId} 所有愿望清单条目的/wishlists/{listId}/entries/
亚马逊愿望清单条目中所有图书的/wishlists/{listId}/entries/amazon/books。

您将在逻辑上获得您心中形成的网址。