假设我有两个资源，user和blog。它们每个都由它们自己的API端点以典型的REST方式表示为:
api/users/api/users/<id>/
api/blogs/api/blogs/<id>/
我还希望能够表示两个订阅之间的多对多关系。一个用户可以订阅多个博客，而多个用户可以订阅多个博客。用户ID和博客ID之间的关系有一个惟一的约束，因此永远不可能有两个条目具有相同的用户ID和博客ID组合。订阅还包含额外的信息，如订阅日期、首选电子邮件频率等客户端可能想要编辑的信息。
用常规REST格式表示这种关系的最佳方式是什么?
当我一直在搜索这个话题时，我一直看到两个选项:
- 使用像
api/users/<user_id>/blogs/<blog_id>/这样的嵌套资源，但对我来说，这意味着响应将是一个博客对象，而不是订阅对象，它具有客户端需要能够与之交互的额外订阅信息。 - 为订阅对象(如
api/subscriptions/<id>/)创建一个离散端点，在此端点中与之交互的对象显然是订阅本身。
我在方法2中遇到的困境与决定特定订阅的唯一标识符有关。在我的数据库中，每个订阅都有一个唯一的自动递增的整数ID，我可以使用它，但是如果客户机可以同时使用用户ID和博客ID访问特定的订阅，这将更加方便，特别是因为组合保证是唯一的。例如，如果用户12想订阅博客34，可以在一个请求PUT api/subscriptions/<some-way-to-specify-user-ID-12-and-blog-ID-34>中完成，后端将检查该组合键是否存在，并更新或创建它。否则，如果使用实际的订阅ID，客户机必须首先执行GET api/subscriptions/?user_id=12&blog_id=34，以便发现要使用的订阅ID(如果存在的话)，然后执行POST api/subscriptions/来创建或PUT api/subscriptions/<subscription_id>/来更新条目。或者这是我想要做的一个双键标识符的一个奇怪的东西?使用自然订阅ID并让客户端搜索它是不是更好?
是否有标准/惯例/推荐的方式来表示这种关系?还有其他我没遇到的选择吗?
您可以同时使用这两种方法，但是考虑好的URI没有多大意义，因为您永远不会将不同的URI硬编码到您的REST客户机中。您的客户机将从服务获得uri，并根据附加到它们的元数据决定遵循哪一个。这个概念和浏览网页是一样的。如果您做了一些不同的事情，那就不是REST。https://www.ics.uci.edu/菲尔丁/酒吧/论文/fielding_dissertation.pdf https://en.wikipedia.org/wiki/HATEOAS