我很好奇 CRUD REST API 将如何实现tweets资源的想法。当然，诸如 Twitter 之类的应用程序具有tweet对象的概念，但应用程序以各种方式（“集合”）需要这些概念。
Twitter 需要一个user时间线端点（tweets由某个用户发布）和home时间线（用户关注的人的推文时间线）。我想，在 CRUD API 中，user时间线将位于 URI，例如：tweets?filter={username:"Bob"}
但是，我不太确定 CRUD API 设计将如何实现home推文的时间线集合。此外，诸如favourites用户的集合——这些集合是完全被视为单独的资源，还是应该以某种方式附加到tweets资源？
此外，Twitter 还没有为他们的 API 使用 CRUD 设计。也许这有充分的理由？
资源设计的好处在于它并不重要，只要它（某些）有意义。显然有些细微差别已经到位，但让我们直奔主题。商业模式不必（必须）将 1:1 映射到资源，这可能就是您在 Twitter API 中找不到这种关系的原因。
一些假设：时间线是预先定义的，他们的行为是不可影响的，其他的通过创建新的推文。收藏夹是（引用）推文。收藏夹是有影响的。
最喜欢的收藏资源，可能是这样的：
/user/bob/favorites您的“CRUD”操作可能类似于：
[POST] /user/bob/favorite{ "tweet_id": "343fe4a" } -- 添加新的收藏夹[GET] /user/bob/favorite-- 用户 Bob 的所有收藏夹[DELETE] /user/bob/favorite/343fe4a-- 删除推文 343fe4a 为收藏通常最好避免在单个资源中使用多个变量，因为这会引入某种不需要的复杂性。然而，在此示例中，收藏夹没有自己的标识符。相反，它重新使用了推文中的标识符，并且它还与用户紧密耦合。
如果收藏夹确实有它自己的标识符，我将着手创建一个资源，例如：/favorite/ef213e13f这可以返回元数据或充当 HTTP GET 方法的推文的别名（重定向）或“取消收藏”的资源（删除方法）。
如果我们不谈论推文，而是谈论带有文章和评论的博客，那么这种说法可能更有意义：
/blog/article/42-- 代表一篇文章/blog/article/42/comments-- 代表本文所有评论的集合/blog/comment/44571-- 代表一条评论根据您的需要，时间线的几个示例可能是资源，例如：
/user/bob/timeline/home/user/bob/timeline?type=home/timeline/home?user=bob正如我之前提到的，最好避免在一个资源中使用多个变量。我可能会选择选项 3。除了具有太多变量的复杂性之外，原因是这样的资源可能不值得缓存（客户端）并且可能不会对其执行 CUD 操作。因为它很可能是不同实体的聚合资源。
几句结束语：
进一步阅读的建议：