需求素材:产品功能对标

一、配置中心

1、分组定义

1.1、分组的区域、独立域名和二级域名

API 分组是 API 的管理单元,分组包含名称、描述、区域(Region)、域名几大属性。

域名:分组创建时,系统会为分组分配一个二级域名。如果需要开放 API 服务,您需要为分组绑定一个在阿里云系统备案成功的独立域名,且将独立域名 CNAME 到相应的二级域名上。每个分组最多只能绑定5个独立域名。

独立域名:用于开放api

二级域名:用于测试,使用有限制

组的QPS限制:500

1.2、环境和环境变量

  • 环境是 API 分组上的一个配置,每个分组有若干个环境。 API 录入后,未经发布时,就只是 API 定义。发布到某个环境后才是能够对外提供服务的 API 。
  • 环境变量是在环境上用户可创建可管理的一种变量,该配置是固定于环境上的。如在线上环境创建变量,变量名为 Path,变量值为 /stage/release.

在 API 定义中的 Path 位置,写作 #Path#,即配置为变量标识,变量名为 Path。

那么将该 API 发布到线上环境时,该 API 在线上环境的运行定义,Path 处的 #Path#,会取值为 /stage/release。

而将该 API 发布到其他环境时,若环境上没有环境变量 #Path#,则无法取值,那么 API 就无法调用。

使用环境变量可以解决后端服务需要区分环境的问题,通过不同的环境上配置不同的服务地址和Path,来调用不同的后端服务,同时 API 的定义配置又是一套。使用时需要注意以下几点:

  • 在 API 定义中配置了变量标识后,在 API 列表—管理—调试 页面将无法调试。
  • 变量名严格区分大小写。
  • 如果在 API 定义中设置了变量,那么一定要在要发布的环境上配置 变量名和变量值,否则变量无赋值, API 将无法正常调用。

1.3、https支持

后端是 https,所以还需要上传 SSL 证书,不支持上传文件,需要把内容复制进来。

若该分组下的 API 支持 HTTPS 协议,您还需要为该独立域名上 SSL 证书。不支持文件上传,需要填写证书名称、内容和私钥。

HTTPS在HTTP的基础上加入了SSL协议,对信息、数据加密,用来保证数据传输的安全。现如今被广泛使用。

API网关也支持使用HTTPS对您的API请求进行加密。可以控制到API级别,即您可以强制您的API只支持HTTP、HTTPS或者两者均支持。

如果您的API需要支持HTTPS,以下为操作流程:

步骤1:准备

您需要准备如下材料:

  • 一个自有可控域名。
  • 为这个域名申请一个SSL证书

    SSL证书会包含两部分内容:XXXXX.key、XXXXX.pem,可以使用文本编辑器打开

    示例:

    KEY

-----BEGIN RSA PRIVATE KEY-----

MIIEpAIBAAKCAQEA8GjIleJ7rlo86mtbwcDnUfqzTQAm4b3zZEo1aKsfAuwcvCud

....

-----END RSA PRIVATE KEY-----

  • PEM

-----BEGIN CERTIFICATE-----

MIIFtDCCBJygAwIBAgIQRgWF1j00cozRl1pZ+ultKTANBgkqhkiG9w0BAQsFADBP

...

-----END CERTIFICATE-----

步骤2:绑定SSL证书

准备好以上材料,需要进行如下操作进行,登陆API网关管理控制台【开放API】-【分组管理】,单击您需要绑定SSL证书的分组,查看分组详情

在绑定SSL证书,您首先需要您在API分组上绑定【独立域名】

【独立域名】-添加SSL证书

  • 证书名称:用户自定义名称,以供后续识别
  • 证书内容:证书的完整内容,需要复制XXXXX.pem 中的全部内容

私钥:证书的私钥,需要复制XXXXX.key中的内容。点击【确定】后,完成SSL证书的绑定。

步骤3:API配置调整

绑定SSL证书后,您可以按API控制不同的访问方式,支持HTTP、HTTPS、HTTP和HTTPS三种,出于安全考虑,建议全部配置成HTTPS。

可以在【开放API】-【API列表】找到相应API,【API定义】-编辑-【请求基础定义】中进行修改。

API支持的协议包括:

    • HTTP:只允许HTTP访问,不允许HTTPS
    • HTTPS:只允许HTTPS访问,不允许HTTP
    • HTTP和HTTPS:两者均可调整后,API支持HTTPS协议配置完成。您的API将支持HTTPS访问。

2、API定义

创建 API 即在 API 网关录入 API 的定义。您需要定义 API 的基本信息、服务信息、请求信息、返回信息。

  • 网关支持您配置对入参的预校验规则,让网关成为您后端服务的第一道关卡。
  • 网关支持您配置前端和后端的全映射,即参数混排。如您可以让您的用户在 Query 传入参数,但是您后端从 Header 里接收,等等。以满足您需要将服务包装变形输出。
  • 网关支持您配置常量参数、系统参数,这些参数对您的用户不可见,但是网关可以在中转时将常量参数、系统参数加入请求中,传递至后端服务,满足您后端的一些业务需求。比如您需要网关每次向您发送请求都带有一个 keyword aligateway,您就可以把 aligateway 配置为常量参数,并指定接收的位置。

2.1、API的基本信息

API 的基本信息:分组、API 名称、API 类型、API 认证方式、描述。

组内的API类型有公开、私有,私有除非有APP得到了授权,默认不会随分组上线

  • API 创建时需要选择分组。分组是 API 的管理单元,创建 API 之前您需要先创建分组( API 分组的详细说明见 API 开放),选择分组即选择 Region。
  • 安全认证方式:是 API 请求的认证方式,目前支持 阿里云APP、OpenID Connect 和 无认证 三种认证方式。
    1. 阿里云APP:认证方式即要求请求者调用该 API 时能够通过对APP的身份认证。
    2. OpenID Connect:是一套基于 OAuth 2.0 协议的轻量级规范,提供通过RESTful APIs 进行身份交互的框架。可以使用OpenID Connect和您的自有账号系统无缝对接,详细介绍请参照 OpenID Connect
    3. 无认证:认证方式即任何人知晓该 API 的请求定义后,均可发起请求,网关不对其做身份验证,均会转发至您后端服务。

API 类型分为公开和私有两种。

  • 私有类型的API ,当所在分组上架云市场时,默认不包括该类型的 API 。如果有用户想要调用您的 API ,您需要主动操作授权,否则用户无渠道获取 API 信息。
  • 公有类型的API ,所有用户

    均有机会在 发现 API页面看到 API 的部分信息。公开 类型的 API 都会跟 API 分组上架到云市场,供用户购买和调用。

2.2、API的前端定义

定义用户如何请求 API ,包括协议、Method、Path、入参的定义。

录入的参数,包括 Path 中的动态参数、Headers 参数、Query 参数、Body 参数(非二进制)、常量参数、系统参数,参数名称保证全局唯一。

  • 协议及method。 API 调用支持 HTTP/HTTPS 协议。
  • Method 方法可选择 PUT、GET、POST、DELETE、HEAD。
  • Path。Path 指相对于服务 host, API 的请求路径。请求 Path 可以与后端服务实际 Path 不同,您可以随意撰写合法的有明确语义的 Path 给用户使用。您可以在请求 Path 中配置动态参数,即要求用户在 Path 中传入参数,同时您的后端又可以不在 Path 中接收,可以映射为在 Query、Header 等位置接收。在 开放 API 接入 API 网关 中,有详细的举例说明,更有清晰的截图展示。
  • 入参。定义您 API 的请求入参,即配置用户需要在什么位置传入什么参数。可选位置有Head、Query、Body、Path(Parameter Path),尤其当您在 Path 中配置了动态参数,那么在入参配置时需要对动态参数做配置说明。支持的参数类型有 String、Number、Boolean。
  • 参数校验规则。每个入参后可点击 编辑更多 配置校验规则。如 String 的长度,Number 的枚举等等。网关会参照校验规则对请求做初步校验,如果入参不合法,则不会到达您的后端服务,大大的降低了后端服务的压力。

配置请求 path

Path 就是您调用 API 时,Url 中 .com 后到 ? 之前的部分,Path 包含动态参数的情况在后续的后端配置步骤中详细说明。
举例说明:比如您调用的 Url 前部分为:https://globalservice.api.com/getapilist?command=...
那么您的 Path 就是:/getapilist

前端入参

参数映射:请求参数映射,前端和后端都支持参数映射,path中支持动态参数!
结果映射: 返回结果目前是直接转发给前端的。
参数类型:
head参数、请求参数、动态参数
body参数:post模式下使用,二进制方式和form方式二选一 
常量参数和系统参数 API 的请求者不可见,由网关在请求后端服务时添加上。 
常量参数:比如您的后端需要接收一个常量,但是这个常量您不希望被您的客户看见,那么就设置一个常量参数,可以在 Header 或者 Query 里面接收。 
系统参数:比如您需要获取客户调用 API 时用的 APP 的 ID 来做日志统计,可在系统参数配置,在 Header 或者 Query 里面接收。建议后端接收 CaRequestId 字段,每个请求一个 ID 唯一,便于问题定位和建立全量日志,再如clientIp。

body是否二进制:只能前后端都为二进制或者都为 form

参数校验:支持参数类型、参数值(范围、枚举、正则、Json Schema)校验,无效校验直接会被 API 网关拒绝

另外,API 网关入参配置是支持混排的,把所有参数在一起配置,然后选择参数的位置是 Header、Query 还是 Body,甚至是在 Path上。

2.3、API的后端定义

定义一些参数的前后端映射,具体描述的后端真实服务的 API 配置。

用户请求到达网关后,网关会根据后端配置映射为对应实际后端服务的请求形式,去请求后端。

API的后端定义包括后端服务地址、后端Path、后端超时时间、参数映射、常量参数、系统参数。

  • 后端访问协议定义:http、https
  • 后端服务地址。后端服务的 host,可以是一个域名,也可以是 http(s)://host:port 的形式。
  • 后端 Path。Path 是您的 API 服务在您后端服务器上的请求路径,实际请求路径。若您后端 Path 需要接收动态参数,那么需要声明该参数是调用者从哪个位置哪个参数传入的,即声明映射关系。
  • 后端超时时间。指 API 请求到达网关后,网关去调 API 后端服务的响应时间。由网关请求后端开始到网关收到后端返回结果。该值不能超过30秒。超过该值网关会放弃请求后端服务,并给用户返回相应的错误信息。
  • 参数映射。网关支持参数在前端、后端的全映射,包括名称映射和位置映射。位置映射包括 Path、Header、Query、Body 的混排映射。也就是说,您可以将您的后端服务通过映射完成包装成更规范、更专业的 API 形态。这部分就是在声明前后端 API 映射关系的。在 开放 API 接入 API 网关 中,有详细的举例说明,更有清晰的截图展示。注意前后端参数名称不能重复。
  • 常量参数。比如您需要网关每次请求您后端时都带有标记 apigateway,那么您可以直接将标记配置为常量参数。常量参数对您的用户不可见,请求达到网关后,网关会自动在指定位置加上该参数再去请求您的后端。
  • 系统参数。指 API 网关的系统参数,这些参数默认不会传递给您,但是如果您需要获取,您可以在 API 里配置接收位置和名称。具体内容如下表:

2.4、API 的结果定义

返回类型及示例,目前网关对于返回结果不做处理,直接透传给请求者。后续会支持用户定制化、格式化的定义返回信息。

多端输出:只需调整API定义,即可实现对APP、设备、web端等多种终端的支持

3、API文档生成

自动生成 API 文档,可供在线查看!

https://apigateway.console.aliyun.com/?spm=5176.doc29496.2.1.cEmnVJ#/cn-hangzhou/apis/detail/66bc382db8344b3b93056c696fab49a8/749965cee13e40af9b2487d0b3380cde/definition

4、API SDK文档下载

 \

5、以函数计算作为 API 网关后端服务

API网关调用函数服务时,会将API的相关数据包装为一个Map形式传给函数计算服务,函数计算服务处理后,需要按照图中Output Format的格式返回statusCode,headers,body等相关数据,API gateway再将函数计算返回的内容映射到statusCode,header,body等位置返回给客户端。

函数计算(Function Compute)是一个事件驱动的服务,通过函数计算,用户无需管理服务器等运行情况,只需编写代码并上传,函数计算准备计算资源,并以弹性伸缩的方式运行用户代码。而用户只需根据实际代码运行所消耗的资源付费。

详细了解请查看函数计算帮助文档

API网关与函数计算对接,可以让您以API形式开放您的函数,并且解决认证、流量控制、数据转换等问题(查看API网关功能) ,让您的函数服务可以安全、简单的以API形式对外开放。

二、网关引擎

1、请求防注入

2、防攻击

3、防注入

4、请求防重放

5、请求防篡改

请求签名支持多种认证方式,支持 HMAC (SHA-1,SHA-256) 算法签名。

6、请求加密:https和加密算法?

7、权限管理:用户权限?

8、流量控制

  • 流量控制可以用于管控 API的被访问频率、APP的请求频率、用户的请求频率。
  • 天、小时、分钟,告警?
  • 支持流控例外,允许设置特殊的 APP 或者用户

三、版本生命周期管理

历史与版本切换

您可以查看您每个 API 的发布历史记录,包括每次发布的版本号、说明、环境、时间和具体定义内容。

查看历史时,您可以选定某个版本然后操作切换到此版本,该操作会使该版本直接在指定环境中替换之前的版本,实时生效。

1、创建

2、测试

  • 线上环境和测试环境
  • 可视化的界面调试工具,快速测试
  • 支持mock

api-online-test和api-mock

对方有测试环境 ?  目前不支持该特性

界面调试工具:提供可视化的界面调试工具,快速测试,快速上线。

  1. 页面可以支持 Mock 或者非 Mock 两种调试。
  2. 选择 Mock,需要写定返回结果,Mock 下调试不会真的去调用后端,但是会把访问后端之前的参数、Path 寻址都校验掉。
  3. 不选择 Mock 则会真实调用后端服务,右侧会返回真实的请求结果,这个结果可以是 API 网关返回的也可以是您后端返回的,看具体情况。

3、发布

当您完成 API 的创建后,您可以将 API 发布到测试或者线上。也可以将测试或者线上的 API 下线。您需要注意以下几点:

  • API 创建完成后,发布到某环境,通过二级域名或者独立域名访问时,需要在请求的Header指定要请求的环境,参见 请求示例
  • 当您要发布某个 API 时,如果该 API 在测试或者线上已经有版本在运行,您的此次发布将使测试或者线上的该 API 被覆盖,实时生效。但是历史版本及定义会有记录,您可以快速回滚。
  • 您可以将测试或者线上的某个 API 下线,下线之后,与策略、密钥、 APP 的绑定或者授权关系依然存在,再次上线时会自动生效。如果要解除关系,需要专门操作删除。

线上环境和测试环境

checklist列表

4、授权管理(线上环境和测试环境)

您的 API 如果上架到市场,那么购买者有权利操作给自己的某个 APP 授权。

如果不经过购买行为,您需要在线下跟合作伙伴建立使用关系,那么您需要通过授权来建立 API 和 APP 的权限关系。

您将 API 发布到线上环境后,需要给客户的 APP 授权,客户才能用该 APP 进行调用。您有权对此类授权操作建立或者解除某个 API 与某个 APP 的授权关系, API 网关会对权限关系进行验证。操作授权时,您需要注意以下几点:

  • 您可以将一个或者多个 API 授权给一个或者多个 APP 。批量操作时,建议不要同时操作多个分组下的 API 。
  • 批量操作时,先选择 API 后选择环境。比如一个 API 在测试和线上均有发布,最后选择了测试,就只会将测试下的该 API 授权。
  • 您可以通过客户提供给您的AppID或者阿里云邮箱账号来定位 APP 。
  • 当您需要解除某个 API 下某个 APP 的授权时,您可以查看 API 的授权列表,在列表页进行解除。

5、下线

6、版本切换,快速回滚

四、监控告警

1、监控

调用量、流量大小、响应时间、错误率

流量控制:按照用户+api,时段有分钟,小时,天

2、告警

可配置预警方式(短信、Email),订阅预警信息,以便实时掌握API运行情况。

3、分析

支持历史情况查询,以便统筹分析。

4、运维

5、历史查询

五、文档和视频

1、开发指南

2、培训视频

3、使用限制

时间: 08-28

需求素材:产品功能对标的相关文章

聚合类新闻客户端产品功能点详情分析

产品功能点 功能 今日头条 百度新闻 鲜果 ZAKER 媒体订阅 × √ ★ ★ 个性化内容推荐 ★ √ × × 个性化订阅(RSS) × × ★ × 视频新闻 × × × × 评论盖楼 √ √ √ √ 搜索新闻 √ ★ × × 离线下载 √ √ √ √ 地方新闻 √ √ × √ 一键分享 √ √ √ √ 收藏 √ √ √ × 推送 √ √ × √ 天气 × × × √ 夜间模式 √ √ √ √ 线上活动 ★ × × ★ 主题设置 × × × √ 感兴趣 √ √ × × 语音读文章 × × ×

市场需求和产品需求有哪些区别和联系?

1.市场需求是问题,产品需求是答案 一个是现象一个是方法 产品需求服务产品,产品服务市场需求,它们应该是因果关系 产品都是为解决某个问题存在的 2.市场需求有伪装性,产品需求要明晰性 就像福特和马的故事,用户真正需求的是要更快的交通工具,但用户只知道马 ,所以他们的需求是有隐蔽性的:福特的产品需求就很明晰了,要做更快的汽车 市场需求是需要挖掘的 3.都是1对多关系 市场需求可以有多个产品来满足,产品需求又可以满足多个市场需求 汽车和马都可以解决交通问题,而且各有优缺点:汽车快但贵,马慢但便宜 搜

聚合类新闻client产品功能点详情分析

产品功能点 功能 今日头条 百度新闻 鲜果 ZAKER 媒体订阅 × √ ★ ★ 个性化内容推荐 ★ √ × × 个性化订阅(RSS) × × ★ × 视频新闻 × × × × 评论盖楼 √ √ √ √ 搜索新闻 √ ★ × × 离线下载 √ √ √ √ 地方新闻 √ √ × √ 一键分享 √ √ √ √ 收藏 √ √ √ × 推送 √ √ × √ 天气 × × × √ 夜间模式 √ √ √ √ 线上活动 ★ × × ★ 主题设置 × × × √ 感兴趣 √ √ × × 语音读文章 × × ×

相关文章、关联文章、产品功能开发方案

内容管理系统,如文章管理.产品管理的时候,经常会出现这样的场景:某篇文章为系列文章,或者为系列产品,然后需要这个系列的文章/产品在展示的时候,展示出同系列的文章或者产品.同时,在后台管理的时候,需要在有关联关系后,能对关联关系进行管理(增删改查). 这样的需求,因为考虑到信息维护的唯一性,原计划是新增数据表,用中间数据表对关键结构进行存储管理,这样更规范,也不用对原来的文章数据进行破坏,不增加大数据量的文章表字段.不过后来考虑到后期在管理的时候,工程量开发更大,就抛弃了这个方案. 还是用最简单的

java模拟手动Telnet过程之需求说明和功能点说明

一.需求 (一)每五分钟查询一次交换机的连接情况: (二)每2.5分钟更新每栋楼的连接情况. 二.功能点 序号 功能点说明 待定 完成 未完成 完成时间 预计用时(min) 实际用时(min) 备注 1 登录口令加密以及解密         60     2 表的创建和IP以及口令写入数据库         10     3 java模拟手动Telnet交换机         90     4 获取目标字符串         30     5 表的创建与当前目标数据的写入         10

掌握需求过程阅读笔记—2

通过对事件驱动的用况.网罗需求.功能性需求这三个章节的阅读.使我们明白了在事件的驱动用况上,我们需要通过一些经验法则来定义用况,发现合适的用况:在网罗需求上,我们最需要做的就是进我们的一切可能去罗列用户的需求,并能及时的与用户沟通交流,确保产品符合最新的要求:在功能性需求方面上我们应当明白它是因为产品的存在的根本原因而存在的需求,它描述的是产品的动作,并能够形成一份完整的尽量避免二异性的功能描述. 事件驱动的用况是业务实践相应(活动和数据)的一部分,这些事件响应有产品来执行.用况成为了需求的锚,

小组成员分工

在Scrum中有三种角色:产品负责人Product Owner,Scrum Master和Team. po(product owner产品负责人)的主要职责是确定产品的功能和完成时间:对产品的收益负责:根据市场需求确定产品功能的优先级:在每个Sprint开始之前,可以修改功能需求和优先级:有权决定接受或否决各Sprint的工作成果. sm的主要职责是是团队的导师和组织者,与Product Owner紧密合作,及时为团队成员提供帮助.促使team按照scrum方式运行,为Scrum过程负责的人.S

从产品和用户角度,思考需求和用户体验

需求来源于生活,用户体验是为了相对核心的需求而产生的新需求,需求的极致就是把一种需求变成习惯. 在产品这个圈子里,经常会遇到两个词,一个叫需求,另一个叫用户体验.在我看的各类产品相关的书籍和文章中,这两个词的出现率也是相当高的.经常在跟别人聊天的时候,也把这几个词挂在嘴边,忽悠忽悠.随着自己的成长和自己眼界的拓展,渐渐地理解了这两个词的意义. 一.需求的思考 从产品人的角度,需求就是产品人能给用户解决的问题.从用户的角度来说,需求就是用户需要产品人解决的问题. 举个例子说,假如某公司PM设计了一

码农的产品思维培养第5节----产品需求的遴选和管理《人人都是产品经理》

这一节主要总结一下苏杰在书中的第2.4节和2.5节的内容. 需求PK在一个互联网公司里面是再常见不过的事情了.PK赢了,那么你的产品就可以立项上马,如果输了,那么别人的产品上了.你呆一边去. 产品需求刷选主要包含:需求打包,BRD制作,产品会议,如果通过则进行立项. 1 准备出发:把需求打个包 我们 产品要实现,在公司内部是要作为一个项目来实现它的.而项目追求的是多快好省的完成任务,这个在后面的章节我们会讲到.所以,你提的需求,一般来说不会给你机会全部去实现的.所以你需要对需求进行排序,选择,打

负责的产品经理是如何跟进需求落地的?

一个产品经理可以随时随地的知晓自己需求的进度,并且能够及时检验,是对产品负责的一个态度. 产品经理中打酱油的节点 最近负责的产品模块进入开发周期,需求评审.产品设计过一段落,是时候歇一口气的周期.往往很多产品经理在这个时候,最常用的是要么在有任务或需求指标下,不快不慢地进入下一个需求:要么是在下一个版本时间.或需求没明确的时候,没有事情的等待产品上线:不得不说这个周期,我认为是评判一个产品经理是否负责的PM. . 有没有跟进时间计划 . 有没有跟进产品节点 . 有没有全局考虑全在这里体现 01