代码之家  ›  专栏  ›  技术社区  ›  harry callahan

复合反应规则?

  •  0
  • harry callahan  · 技术社区  · 9 年前

    我已经阅读了很多文章和Apigee文档以及从实用角度设计RESTful API的最佳实践。但是,有一件事我无法完全感觉到,为API的使用者构建一种设施,以便在同一文档中选择性地包含其他资源,是好是坏。

    我的直觉是,通常应避免以下情况:-

    /accounts?include=transactions
    
    { accounts: [
        { "id": "101",
          ... 
          "transactions": [ ... ]
        },...
    

    最好有:-

    /accounts
    
    { accounts: [
        { "id": "101",
          ... 
          "transactions": /link/to/transactions/for/acccount
        },...
    

    然后

    /transactions
    
    { "transactions": [
        { "id": ...
    

    我不介意遵守REST的纯粹主义原则,例如HATEOS等。我之所以这么认为,主要原因是:-

    1. 可选加载 /transactions 到我的 /accounts 这意味着这会在提供API的服务组件之间引入耦合——这与体系结构无关(Monolith或Microservices)

    这是一个公平的论点/方法吗?

    1 回复  |  直到 9 年前
        1
  •  0
  •   VoiceOfUnreason    9 年前

    你可能还想调查 sidecar embedding .

    但是,有一件事我无法完全感觉到,为API的使用者构建一种设施,以便在同一文档中选择性地包含其他资源,是好是坏。

    嗯,这可能不是其中任何一个。它可能适合或不适合您的用例,但在正确的设置中,情况可能正好相反。

    这就是说,如果你是从REST的角度思考,那么看看参考实现(WWW)做了什么也无妨。网页上主要的超媒体类型是HTML;您已经得到了表示法,并链接到了辅助表示法,但绝对不能模拟“这是本文档链接到的某个内容的表示法,以防万一”。

    换言之,“链接到所有内容并让缓存进行整理”是一个公认的、非常成功的先例。菲尔丁自己 wrote

    查询结果由包含摘要信息的链接列表表示,而不是由对象表示数组表示(查询不能替代资源标识)。

    另一个折衷方案是支持两种资源;一个带有链接的向下配对版本,一个带有嵌入数据的丰富版本。 GetEventStore 有这种模式,有三种不同的资源

    http://127.0.0.1:2113/streams/newstream2
    vs
    http://127.0.0.1:2113/streams/newstream2?embed=rich
    vs
    http://127.0.0.1:2113/streams/newstream2?embed=body
    

    你可以提供两种陈述的链接,让你的客户选择最适合他们的情况;或者(如果使用的是HATEOAS),则可以控制哪些链接关系出现在哪些表示中。

    (另一种可能性是有一个资源,但每个表示都有一个单独的媒体类型)。

    您可能还想考虑,“聚合”资源(负责对您的域模型进行修改)可能不同于许多支持查询但不进行修改的“投影”资源。这就是CQRS方法。

    吉姆·韦伯(Jim Webber):“与业务领域中的业务对象相比,您应该期望在集成领域中拥有更多的资源。”