sql - REST API体系结构: How to Represent Joined Tables

Question

问题
我有一个复杂的查询，该查询连接三个表并返回一组行，每一行都包含来自其同级表的数据。如何以RESTful方式表示这一点？
FWIW我知道不一定有“正确”的方法来做，但是我有兴趣了解什么是这种情况下最可扩展和持久的解决方案。
背景
过去，我代表的单个表或多或少地反射(reflect)了url的文字结构。例如，URL GET /agents/1/policies将导致类似select * from policies where agent_id = 1的查询。
假设
似乎url不一定必须与数据库层的结构紧密耦合。例如，如果复杂的查询是这样的:

select
  agent.name as agent_name,
  policy.status as policy_status,
  vehicle.year as vehicle_year
from
  policies as policy
  join agents as agent on policy.agent_id = agent.id
  join vehicles as vehicle on vehicle.policy_id = policy.id
where 1=1
  and policy.status = 'active';

# outputs something like:
{ "agent_name": "steve", "policy_status": "single", "vehicle_year": "1999" }

我可以将这个QUERY表示为一个网址，而不是将TABLES表示为该网址。这个网址可以是 /vehicles，如果有人要查询它(使用id或其他参数，例如 /vehicles?vehicle_color=red)，我可以将该值传递到准备好的语句中。
奖励问题

这是反模式吗？

我的查询是否应该始终针对现有表而不是针对准备好的语句运行？

谢谢你的帮助!

Answer 1

您想从数据库表和查询​​中退后一步，然后考虑一下基本资源。在您的示例中，很明显，这些是agent，customer vehicle和policy。

资源与馆藏

我在您的示例中看到的一个失误是，您没有使用复数将集合与资源分开，这在处理 Controller 路由和进行逻辑搜索时非常有用。在您的示例中，您具有:
GET /agents/1/policies
假设这是GET /agent/1/policies。

现在，您可以清楚地知道等幂资源的位置/agent/1和查找/搜索代理集合:/agents。

但是，按照这一过程，您将开始从API的关系的各个方面解除枚举关系的关联，这本质上是多余的。

在您的示例中，显然策略不是由代理专门拥有的。一个策略应该是一个独立的资源，它可以通过某个等幂url来标识，该ID使用唯一标识该策略的ID来找到该策略。 /policy/{Id}
搜索集合

现在，这可以为您提供服务，使您可以通过以下方式将对策略的发现分开:/policies，其中仅返回特定Agent的策略只是您访问该集合的多种不同方式之一。

因此，与其使用GET /agents/1/policies，您不如通过以下方式找到与代理相关的策略:GET /policies?agent=1
预期的结果将是匹配策略的资源标识符的集合:

{ "policies" : ["/policy/234234", "/policy/383282"] }

然后如何获得最终结果？

对于给定的策略，仅在没有select子句的限制的情况下，您会期望完全返回关联信息(如查询中一样)。由于您想要的是过滤后的版本，因此处理该问题的方法将包括过滤条件。
GET /policy/234234?filter=agentName,policyStatus,vehicleYear
话虽如此，这种方法还是有陷阱的，出于多种原因，我对该方法提出了质疑。如果您查看原始的资源列表，则每个资源都可以视为一个对象。如果要在客户端中构建对象图，则策略的完整信息将包括所有关联资源的资源定位符:

{ ... Policy data + "customer": "/customer/2834", "vehicle": "/vehicle/88328", "agent": "/agent/32" }

客户的职责是访问代理商，车辆和客户的数据，而不是在您需要对数据进行任何查看时重复冗余地对所有数据进行重复的工作。

这样比较好，因为它既安静，又支持REST的许多目标，以支持幂等性，缓存等。

这也更好地允许客户端在本地缓存代理的数据，并确定它是否需要获取该数据或仅访问已缓存的数据。在最坏的情况下，可能需要进行3或4个REST调用。

奖励问题

REST有一些灰色区域。您必须解释菲尔丁(Fielding)，因此，关于如何做事经常会有不同的意见。虽然经常使用提供类似 GET /agents/1/policies之类的api来提供与代理相关联的策略列表的方法，但根据我的经验，这有时会变得局限性和冗余，因为这需要最终用户熟悉您的方式。建立与基础资源的关系模型。

至于查询问题，只要您保持一致，访问基础数据和组织数据的方式就没有关系。经常发生(出于性能目的)是api不返回资源标识符，而是开始返回数据，如前所述。这是一个湿滑的斜坡，您只是将REST api变成了一堆查询的前端，此时您的API可能就是: GET \query?filter=agent.name, policy.status, vehicle.year&from=policies&join=agents,vehicles&where=...