如何最好地用REST中的附加信息来表示多到多的关系？

Question

让我说我有两个资源，用户和博客。它们以典型的REST方式由各自的API端点表示为：

api/users/

api/users/<id>/

api/blogs/

api/blogs/<id>/

我还希望能够代表这两种订阅之间的多对多关系。用户可以订阅许多博客，博客可以被许多用户订阅。这种关系对用户ID和博客ID有一个唯一的限制，因此永远不会有两个具有相同用户ID和blog ID组合的条目。订阅还包含额外的信息，如订阅日期、首选电子邮件频率等客户端可能希望编辑的信息。

用传统的REST格式表示这种关系的最佳方式是什么？

我一直在寻找关于这个主题的两种选择：

1. 使用像api/users/<user_id>/blogs/<blog_id>/这样的嵌套资源，但对我来说，这意味着响应将是一个博客对象，而不是订阅对象，而订阅对象具有客户端需要与之交互的附加订阅信息。
2. 为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，并让客户搜索它？

是否有一种标准/常规/推荐的方式来表示这种关系？还有其他我没有想到的选择吗？

Answer 1

您可以同时使用这两种URI，考虑好的URI没有多大意义，因为您永远不会将不同的URI硬编码到REST客户机中。您的客户端将从服务中获取URI，并根据附加到它们的元数据决定要遵循的URI。这个概念和浏览网页是一样的。如果你做了不同的事情，那就不是休息。https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf https://en.wikipedia.org/wiki/HATEOAS