云服务器内容精选

  • MoXing MoXing是ModelArts自研的组件,是一种轻型的分布式框架,构建于TensorFlow、PyTorch、MXNet、MindSpore等深度学习引擎之上,使得这些计算引擎分布式性能更高,同时易用性更好。MoXing包含很多组件,其中MoXing Framework模块是一个基础公共组件,可用于访问OBS服务,和具体的AI引擎解耦,在ModelArts支持的所有AI引擎(TensorFlow、MXNet、PyTorch、MindSpore等)下均可以使用。 MoXing Framework模块提供了OBS中常见的数据文件操作,如读写、列举、创建文件夹、查询、移动、复制、删除等。 在ModelArts Notebook中使用MoXing接口时,可直接调用接口,无需下载或安装SDK,使用限制比ModelArts SDK和OBS SDK少,非常便捷。 详细指导:《MoXing开发指南》
  • 如何获取临时AK/SK/securityToken? 您可以通过如下方式获取临时AK/SK/securityToken。 调用 统一身份认证 服务( IAM )的通过token获取临时访问密钥和securitytoken接口获取。 通过统一身份认证服务(IAM)的SDK获取,具体请参见获取临时AK/SK/securityToken。 如果在调用通过token获取临时访问密钥和securitytoken接口时返回404,可能是由于账户开启了MFA验证导致,您可以参考如何解绑MFA进行解绑。 父主题: API&SDK使用
  • 计费示例 以包年/包月计费模式为例,假设您在2023/07/08 15:50:04购买了API数据安全防护实例的专业版。购买时长为一个月,并在到期前手动续费1个月,则: 第一个计费周期为:2023/07/08 15:50:04 ~ 2023/08/08 23:59:59 第二个计费周期为:2023/08/08 23:59:59 ~ 2023/09/08 23:59:59 图2 包年/包月实例计费示例
  • 目的 主要用于指导伙伴、开发者在华为云API中心生产和开放API。通过统一的API治理框架和规范,帮助伙伴、开发者构建并提供有质量保障的 API服务 ,为平台营造良好能力开放与交互的环境,支撑华为云和伙伴及开发者共建API生态。 API治理规范主要从安全、可用性、易用性、可维护性,生命周期管理六个维度针对API生产(API设计/开发/测试)和API开放提供规则建议。 安全:对API的安全认证、涉及敏感信息或个人隐私数据使用和处理提出规范要求或建议,保障API的安全合规。 可用性:对API调用成功率、响应时长、并发及流量控制、吞吐量等提出规范要求或建议,保障API的高可用性。 易用性:对API参考文档描述、入参和出参、消息头定义等提出规范要求或建议,提升API调用者使用体验。 可维护性:对于API兼容性、日志实时性和完整性、版本管理等提出规范要求或建议,提升API可维护性。 生命周期管理:对API变更和下线等提出规范要求或建议,保障已订阅API租户的业务连续性。 包含Must类型的基本规则以及Should类型的扩展规则。Must规则牵引API开发者提供符合企业级标准、安全合规的API,Should规则在提供更全面指导的基础上,给予开发者灵活的弹性空间,方便开发者更快地加入API生态圈。
  • 签名密钥 签名密钥由一对Key和Secret组成,用于后端服务验证API网关代理的身份,在API网关代理请求后端服务时,保障后端服务的安全。 当签名密钥绑定API后,API网关代理向后端服务发送此API的请求时,会增加相应的签名信息,此时,后端服务依照同样方式进行签名并得到签名结果,如果签名结果和API网关代理传过来的Authorization头中的签名一致,则可证明API请求确实来自API网关代理,而不是其他伪造请求。
  • API接口变更在参考文档中为新版本提供迁移计划 本条规则是Should类型的扩展规则,可方便管理API的生命周期。 在进行新版本API设计时应当考虑老版本升级迁移计划,从而实现API的迁移。新版本中继承的接口在语义上应当能兼容老版本。 对于计划不再支持的接口,需要正式发布接口变更公告,应当至少提前6个月在文档标识(使用@deprecated)为不建议使用(在此期间该接口仍要能完成正常的功能),并提供替换方式的处理。 新版本API为兼容旧版本,增加的字段不建议作为强制填写的字段,字段取值范围不建议小于原有的取值范围。
  • API文档记录API接口变更 本条规则是Should类型的扩展规则,可方便管理API的生命周期。 API接口的变更,要具体到参数级别,必须将API修订的记录按照时间和版本顺序排列进行条目化,具体示例如表1所示。 表1 API修订记录 时间 版本 变更内容 2021-07-15 V1.0 XXX服务API初始发布 2021-09-20 V1.1 XXX的API,增加XXX字段,用于XXXX功能;增加XXX字段,用于XXX功能。 XXX的API,增加XXX字段,用于XXX功能。
  • API文档按照模板进行写作 本条规则是Should类型的扩展规则,可提升API调用者的使用体验。 API对外开放时,API文档建议使用统一的模板,以便保持API参考文档的一致性,易于开发者理解。在API参考文档中必须包含如下内容: API目录,包括本次提供API的列表信息。 API名称及API功能介绍。 API请求方法和URI。 API请求参数说明,包括Header、Query参数,需要明确字段内容和取值范围。 API请求Body内容,Body内容需要明确请求结构体内容及各个字段的取值范围。 API响应状态码,状态码及对应的说明。 API响应参数说明包括Header参数,需要明确字段内容和取值范围。 API正常响应Body内容,正常响应Body内容需要明确响应结构体内容及各个字段的取值范围。 API异常响应Body内容,异常响应Body中描述及说明。
  • API请求URI中如果存在特殊字符,需要进行转义编码 本条规则是MUST类型的基本规则,可保障API的高可用性。 某些字符,由于有特殊含义或者系统保留,容易被 Web应用防火墙 或者安全访问控制产品所阻断,导致URI调用不生效,因此不建议在URI中使用,如果必须要用需要用转义编码替换。 转义说明可参考:RFC 2396(Uniform Resource Identifiers (URI): Generic Syntax)。
  • API响应报文使用分页,避免超长列表数据返回 本条规则是Should类型的扩展规则,可提升API调用者的使用体验。 获取资源集合的API建议支持分页。当资源数量较多时服务的查询API需要支持分页,避免一次查询获取的资源数量过多。 不支持分页查询,则服务应该要设置一个显示条数的默认值,避免一次返回过多资源。默认返回数量需要在接口参考中对外说明,避免调用者以为查询出了全量信息。查询条件中可以设定查询数量(limit),位移量(offset)。查询资源列表需要返回符合查询条件的资源总数(count)、查询数量(limit)、位移量(offset)。 举例:查询虚拟机从第10条开始,查询后100条。 请求 GET /ecs/v1/projects/xxxxx/servers?offset=10&limit=100 响应 {"resources":[ { "id":"xxx",},… { "id":"xxx", }], "offset":10, "limit":100, "count":1540}
  • REST REST(Representational State Transfer,表征状态转移)网络上的所有事物都可被抽象为资源,每一个资源都有唯一的资源标识(resource identifier),对资源的操作不会改变这些标识,所有的操作都是无状态的,使用标准方法操作资源。 RESTful风格的服务接口需定义:操作名、URL、请求和响应消息体和响应状态码。 本文后续章节将分别描述接口各部分的定义规范。
  • API请求设置媒体类型和编码格式,响应内容格式需与响应设置媒体类型和编码格式一致 本条规则是MUST类型的基本规则,可保障API的高可用性。 在API请求中对媒体类型和编码格式的正确定义有助于服务端对请求体进行格式校验,避免出现因请求消息体格式错误导致的执行异常。 API响应内容格式需要与响应设置媒体类型和编码格式一致。在API响应中对媒体类型和编码格式的正确定义有助于服务端对请求体进行格式校验,避免出现因请求消息体格式错误导致的执行异常。 API的默认媒体类型为“Content-Type: application/json”和“charset=UTF-8”。 当使用非application/json媒体类型时,建议根据情况选择合适的媒体格式,具体情况如表2所示。 表2 常见的媒体类型 分类 场景 媒体类型 文件上传/下载类 文件上传下载类的接口,直接传递的是文件内容。 须知: 不建议使用该API进行文件传输。 application/octet-stream 表单提交 主要用于界面表单提交,该方法目前已经不属于主流提交手段,建议使用JSON格式进行表单提交。 application/x-www-form-urlencoded 混合多部分类型 传递混合多部分内容类的接口,比如既有文本内容,表单内容,也有二进制文件的。 multipart/form-data SOAP协议 调用以SOAP协议的WebService。 text/xml或application/xml 纯文本类型 仅传递纯文本内容。 text/plain
  • API描述信息必须易于理解,表述准确 本条规则是Should类型的扩展规则,可提升API调用者的使用体验。 API描述信息要易于理解,字面表述准确,能说明API的用途,场景及约束。 API描述信息建议使用Markdown格式编写,便于生成对应API文档,API描述信息长度建议不超过2000字符。 例如:发布API用于查询虚拟机列表。良好的API描述应为“通过虚拟机名称、IP地址、虚拟机型号查询当前租户下的虚拟机列表,列表包括虚拟机名称,所属VPC、虚拟机IP、虚拟机型号、操作系统版本。”
  • API响应状态码应使用规范的HTTP状态码 本条规则是MUST类型的基本规则,可保障API的高可用性。 API响应所使用的状态码应使用规范的HTTP状态码,状态码所表达的状态与API响应状态保持一致。 具体的HTTP状态码使用可参考RFC 7231(Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content),常用状态码如表1所示。 表1 常用状态码 状态码 状态码表示 状态码详细信息 200 OK 执行成功,如:查询成功响应。 201 Created 创建成功,如:创建记录成功。 400 Bad Request 客户端请求语义有误,当前请求无法被服务器理解或请求参数有误。 401 Unauthorized 当前请求需要用户验证,需要用户提供Token进行认证。 403 Forbidden 禁止访问某些资源,如权限不足时无法查询对应的信息。 404 Not Found 无法找到对应资源,如资源不存在。 405 Method Not Allowed HTTP方法不能被用于请求相应的资源如:HTTP方法要求POST方法,请求中使用了GET方法。 406 Not Acceptable 请求资源的内容特性无法满足请求头中的条件。 413 Payload Too Large 请求提交的实体数据大小超过了服务器够处理的范围。 414 URI Too Long 请求的URI长度超过了服务器能够解释的长度。 415 Unsupported Media Type 当前请求的方法和所请求的资源,请求中提交的实体并不是服务器中所支持的格式。 500 Internal Server Error 服务器遇到了一个未曾预料的状况,导致了它无法完成对请求的处理。通常是服务器内部产生了错误,导致处理失败。 502 Bad Gateway 代理服务器尝试执行请求时,从上游服务器接收到无效的响应。
  • API名称必须易于理解、见名知义 本条规则是Should类型的扩展规则,可提升API调用者的使用体验。 API名称要简洁、易于理解、见名知义,建议按照“动词+名词”格式。 在生产环境的API不能包含“test、uat、sit、beta”等字样,API名称只支持中文、字母、数字以及“_”或者"-",API名称长度建议不超过150字符。 例如:易于理解的API名称应为“查询虚拟机列表”/“ListServers”、“创建VPC网络”/“CreateVPC”