我正在设计一个API，我想问一些关于如何最好地保护数据访问权限的问题。
假设API允许访问艺术家。艺术家有专辑，有歌曲。
API的用户可以访问所有艺术家的子集。如果用户调用API要求某位艺术家，则很容易检查是否允许用户这样做。
接下来，如果用户要求提供相册，则API必须检查相册是否属于允许用户访问的艺术家。访问歌曲意味着API必须先检查相册，然后才能检查艺术家。
在数据库方面，我正在研究每个附加层的表之间的连接数量越来越多。我不想做所有这些连接，我也不想在任何地方存储用户ID以限制连接数。
为了解决这个问题，我提出了以下方法。
API为用户提供对象的引用，例如艺术家对象。然后，用户可以向该专辑询问该艺术家对象，该专辑返回列表对象。可以遍历列表对象，并可以从中获取相册对象。同样，从专辑对象中可以获得歌曲列表对象，并从中获得单个歌曲对象。
由于API信任艺术家对象，因此它还信任用户从中获取的任何对象（在这种情况下为专辑），而无需进一步检查。等等所有其他对象。所以我将安全/信任委托给链中的对象。
我想问你对它的看法，它的好坏，当然还有你如何解决这个“问题”。
其次，如果API应该是RESTful，你会如何处理？在这种情况下，我的方法似乎不太适用。
答案 0 :(得分：2)
这是一个真实的程序还是说明问题的样本？ 因为不清楚为什么要限制对艺术家和专辑的访问，而不仅仅限于单个媒体项目甚至是曲目。
我不认为连接应该花费你那么多，当你在多个表上进行相当简单的标准匹配时，任何半智能数据库系统都会足够便宜。
恕我直言，将这么多安全逻辑放入查询中的问题在于它限制了您处理更复杂的DRM问题的能力，这些问题肯定会受到限制。例如，如果专辑是来自多位艺术家的集合怎么办？如果专辑包含一首二重奏曲目并且我只能访问一位艺术家，该怎么办？等等。
我的观点是，在这些情况下，具有合理异常的方便编程模型比单个查询的性能重要得多，您可以在将来缓存或优化这些查询。你试图用查询做什么听起来像是过早的优化。
尽可能灵活地设计您的编程模型。定义一种明智的扩展感，然后在分析真实系统后，实现数据库并优化查询。
答案 1 :(得分：0)
进行连接可能比你的对象方法快得多（虽然它更优雅）。使用联接，您只有一个数据库请求，您拥有的对象很多。 （或者您必须在第一个请求中检索所有“可能”的数据，这也可能会减慢速度）
我建议进行连接。如果有关于sql的问题，你可以在stackoverflow上询问：D
另一个想法：
如果你制作像“/ beatles / whitealbum / happinesisawarmgun”这样的网址
然后你会在请求开始时知道艺术家并且可以在不遍历的情况下立即获得许可 - 因为url包含遍历信息。只是一个想法。
答案 2 :(得分：0)
最好为每个资源包含一个安全描述符，而不仅仅是顶级资源。在您的示例中，安全描述符只是艺术家的ID或艺术家ID的列表，如果您支持二重奏等。所以我会考虑将ID列表添加到艺术家和歌曲表中。您可以添加字符串字段，以逗号分隔的方式写入资源的艺术家ID。
此类解决方案可以很好地扩展，您可以添加更多层，而不会增加安全检查所需的时间。除了要插入的另一个字段（基于资源的父字段）之外，添加新资源也不需要任何额外的惩罚。当然，这个解决方案支持上面描述的特殊情况（比如不止一个艺术家等）。
这种解决方案也不违反RESTful架构。
事实上，每个资源都包含自己的安全描述符，可以概括资源的访问权限，从而可以在将来实现一些完全不同的安全策略（例如，根据相册，而不仅仅是艺术家，使访问权限更加精细）