我正在使用具有非常复杂的访问控制规则的系统中的API.通常,需要复杂的SQL查询来确定用户是否具有对特定资源的读取或写入访问权限.这会在我们的客户端应用程序中造成很多复杂性和冗余,因为他们必须知道所有这些规则,以确定是否为每个对象呈现用户CRUD选项.
我的目标是减少客户端的大部分复杂性,并容纳API中的所有复杂逻辑.这样,在确保UI仅向用户提供有效选项时,针对我们的API编写的新客户端应用程序可以避免重新实现复杂的访问规则逻辑.
我不确定最好的办法是什么.我正在考虑两种不同的选择,但我不知道是否有更好或更标准的方法向API的调用者公开通用访问信息.
当调用者对资源实体或它们的集合发出GET请求时,每个返回的实体都将返回一个_allowed_actions附加的字段,该字段是允许调用者在该实体上执行的一系列操作.例如,请求Listing对象可能导致以下响应.
GET/listing/5
{
"id": 5,
"address": "123 Foo Street",
"city": "New York",
"state": "New York",
"price": 457000,
"status": "pending",
"_allowed_actions": ["READ", "UPDATE", "DELETE"]
}
仍然不确定如何与客户关联他们是否有权使用此方法创建资源实体的实例,但客户可能只需要保持对权限结构的充分理解以自行确定.围绕创建实例的访问规则通常不如READ/UPDATE/DELETE访问规则复杂,因此看起来并不太糟糕.
创建一个元API,客户端可以向其发出请求,以确定它们可以对每个资源执行哪些操作.例如,检查客户端可以对列表执行的操作:
GET/access-query/listing/5
{
"allowed_actions": ["READ", "UPDATE","DELETE"]
}
并检查一般的列表允许的选项,包括CREATE:
GET/access-query/listing
{
"allowed_actions": ["READ", "CREATE", "UPDATE", "DELETE"]
}
这种方法的好处是它允许呼叫者以通用方式完全理解他们可以对每个资源做什么.这样,客户端就不必理解为了创建列表,需要"create_listing"权限和非试用用户状态.他们可以提前查询此信息.
这种方法的缺点是它增加了请求量.他们现在必须查询一次以确定他们可以做什么以及第二次执行此操作,而不是要求客户端了解权限逻辑.
我并不特别关心这些方法中的任何一种,但我现在只能提出这些方法.有没有更好的方法来解决这个问题？