Node.js 微服务之间的数据验证

Node.js 微服务之间的数据验证,node.js,rest,design-patterns,microservices,Node.js,Rest,Design Patterns,Microservices,假设我有3个微服务书籍,作者,附件 作者希望为该书添加封面图像 一旦作者从图库中选择了图像,文件就会以作者id(用户id)上传到附件服务中,并返回一些元数据,如us{id:1} 第二个API将附件与类似书本的follow相关联 现在Book服务必须验证以下内容 id为1的附件是否存在 如果存在,它应该验证当前作者(用户)是附件的所有者 方法1: 在附件服务中创建API端点,返回{id:1,authorId:1},然后我可以验证附件元数据。但它最终会在另一个API调用(往返)中结束 方法2 用

假设我有3个微服务
书籍
作者
附件

作者希望为该书添加封面图像

  • 一旦作者从图库中选择了图像,文件就会以作者id(用户id)上传到附件服务中,并返回一些元数据,如us
    {id:1}

  • 第二个API将附件与类似书本的follow相关联

  • 现在Book服务必须验证以下内容

  • id为
    1
    的附件是否存在
  • 如果存在,它应该验证当前作者(用户)是附件的所有者
  • 方法1:

  • 在附件服务中创建API端点,返回
    {id:1,authorId:1}
    ,然后我可以验证附件元数据。但它最终会在另一个API调用(往返)中结束
  • 方法2

  • 用户上传图像后,不返回元数据中的附件id,例如us
    {id:1}
    返回签名id
    {id:sign(authorId,attachmentId,secret)}

  • 书评拥有相同的
    secret
    ,可以解码和验证附件id和作者id,从而避免多次API调用

  • 方法2有缺点吗

    现在Book服务必须验证以下内容

    • id为1的附件是否存在
    • 如果存在,它应该验证当前作者(用户)是附件的所有者
    在这两点上你是非常正确的,但我想让你想想什么样的服务应该拥有它们。 事实上,
    id=1
    的附件的存在是
    attachments
    服务的责任,因此您需要执行API调用以确保响应不是
    404

    但是,当前作者验证应该在图书服务中进行,因为它是针对图书更新操作进行的。因此,我认为正确的方法是将
    作者id
    存储在
    附件
    服务中,这样当您按id查询附件时,它不仅返回记录存在,还返回作者id。简单地说
    GET/attachments/1
    返回
    {id:1,author\u id:1}


    然后,当作者做了
    PUT/books/1/cover image
    时,您可能会从令牌中提取
    作者id
    ,并可以验证该
    id
    是否等同于
    附件中的
    作者id
    服务,这基本上就是您想要验证的。

    我已经更新了问题,我的问题是,我们是否可以使用一些
    签名算法,而不是使用API调用来验证资产是否存在。
    
    PUT /books/1/cover-image
    payload: {id: 1}