Rest 为最终用户屏蔽公共API后面的多个API

Rest 为最终用户屏蔽公共API后面的多个API,rest,session-state,api-design,Rest,Session State,Api Design,注意:我想首先指出,这个查询的性质非常一般,因为我正在探索实现某种东西的方法,而不是试图解决特定的编码问题 我正在从事一个中间件项目,它位于一组生产者(信息)和一个消费者之间 以下是要求 1) 生产者都为消费者生成数据,但都有自己的API接口 2) 消费者并不真的想为每个生产者的API编码,因此要求创建一个透明层,抽象所有生产者,并为其提供一个API接口来编码 3) 将不时增加更多的生产商 4) 每个生产商发送的信息本质上是类似的类型(例如,股票持有量——包含一组定义的公共属性)。但是,各生产商

注意:我想首先指出,这个查询的性质非常一般,因为我正在探索实现某种东西的方法,而不是试图解决特定的编码问题

我正在从事一个中间件项目,它位于一组生产者(信息)和一个消费者之间

以下是要求

1) 生产者都为消费者生成数据,但都有自己的API接口

2) 消费者并不真的想为每个生产者的API编码,因此要求创建一个透明层,抽象所有生产者,并为其提供一个API接口来编码

3) 将不时增加更多的生产商

4) 每个生产商发送的信息本质上是类似的类型(例如,股票持有量——包含一组定义的公共属性)。但是,各生产商的API中的表述由其自行决定

5) 消费者和每个生产者之间必须进行安全通信,生产者在提供数据之前验证消费者

我相信您可能对这些要求有疑问,或者需要更多的澄清,因此请让我知道,我将更新问题

然而,这里是我的问题,希望这里的一些专家能提供一些建议和指导

A) 我倾向于使用RESTful API为消费者提供JSON响应,并在后端使用JAVA组件进行翻译。这将使它可以扩展以添加更多的生产者(并且他们所有的怪癖和随意性表现都可以从消费者那里抽象出来)。你认为这是一个好主意还是你会建议一个替代方法

B) 这里有身份验证和不可否认性的元素。每个生产商可能都有自己的实现方法-通过数字签名、令牌和访问代码、发送给消费者的一次性密码作为2因素身份验证等。关于如何实现和标准化的任何提示?我应该考虑哪些技术?

C) 由于需要维护身份验证会话,这是否违反RESTful原则


非常感谢您提供的任何帮助或反馈。

我将尝试向您介绍如何解决此问题

  • 从消费者开始-你说你只有一个消费者,这样你就可以很容易地理解消费者期望的API交互类型。然后,您可以设计中间件必须公开的API草案。这将帮助您设计和开发中间件功能

  • 收集所有认证要求-列出“生产者”要求的所有认证类型,并记住每个消费者“用户”必须提供所有认证类型所需的所有信息

  • 身份验证中间件-利用从第2点获得的信息,设计一个身份验证中间件,该中间件可以管理生产者所需的所有身份验证方法。这意味着要考虑一种管理所有生产者凭证的方法此组件仅与逻辑中间件交互

  • 逻辑中间件-顾名思义,管理所有组件交互

    a。向消费者提供简单身份验证,例如简单api令牌

    b。使用专有的域模型,这将使您从生产者的特定域中解放出来,尽管您说生产者的特定域是一致的,并且有助于您设计更自由的集成功能,并与所有参与者分离

    c。从使用者提供的api令牌开始使用身份验证中间件,以便对特定编排中涉及的每个生产者进行身份验证

  • 希望这能帮助你