API概述
通用说明
EDAP服务域名
| 区域 | 服务端点 | 协议 | regionID |
|---|---|---|---|
| 北京 | edap.bj.baidubce.com | HTTP and HTTPS | bj |
| 广州 | edap.gz.baidubce.com | HTTP and HTTPS | gz |
| 苏州 | edap.su.baidubce.com | HTTP and HTTPS | su |
| 保定 | edap.bd.baidubce.com | HTTP and HTTPS | bd |
注意： Region(区域)代表着一个独立的地域，是百度智能云中的重要概念，请参考区域选择说明。百度智能云中的服务除了极少数如账号服务全局有效之外，绝大部分服务都是区域间隔离的，每个区域的服务独立部署互不影响，服务间共享数据需要通过显式拷贝完成，在API中引用区域必须使用其ID。 为了保证整体服务的高效，EDAP的服务区域会和BMR的服务区域保持一致。北京区域的EDAP服务可以纳管北京区域创建的BMR资源，以此类推。
认证机制
所有API的安全认证一律采用Access Key与请求签名机制。 Access Key由Access Key ID和Secret Access Key组成，均为字符串。 对于每个HTTP请求，使用下面所描述的算法生成一个认证字符串。提交认证字符串放在Authorization头域里。服务端根据生成算法验证认证字符串的正确性。 认证字符串的格式为
bce-auth-v{version}/{accessKeyId}/{timestamp}/{expirationPeriodInSeconds}/{signedHeaders}/{signature}
- version是正整数。
- timestamp是生成签名时的UTC时间。
- expirationPeriodInSeconds表示签名有效期限。
- signedHeaders是签名算法中涉及到的头域列表。头域名之间用分号（;）分隔，如host;x-bce-date。列表按照字典序排列。（本API签名仅使用host和x-bce-date两个header）
- signature是256位签名的十六进制表示，由64个小写字母组成。
当百度智能云接收到用户的请求后，系统将使用相同的SK和同样的认证机制生成认证字符串，并与用户请求中包含的认证字符串进行比对。如果认证字符串相同，系统认为用户拥有指定的操作权限，并执行相关操作；如果认证字符串不同，系统将忽略该操作并返回错误码。鉴权认证机制的详细内容请参见鉴权认证机制。
通信协议
支持HTTP和HTTPS两种调用方式。为了提升数据的安全性，建议通过HTTPS调用。
公共头域
请求头
| 头域 | 说明 |
|---|---|
| host | 详见 EDAP服务域名 |
| Authorization | 详见 鉴权认证机制 |
| x-bce-date | 该请求创建的时间，表示日期一律采用yyyy-MM-dd方式，例如2023-06-01表示2023年6月1日。如果用户使用了标准的Date域，该头域可以不填。当两者同时存在时，以x-bce-date为准。 |
| content-type | 默认为: application/json |
| x-bce-content-sha256 | 表示内容部分的SHA256签名的十六进制字符串，其中内容指HTTP Request Payload Body，即Content部分在被HTTP encode之前的原始数据。 |
| x-bce-if-match | 同If-Match语义。 |
| x-bce-if-none-match | 同If-None-Match语义。 |
响应头
| 头域 | 说明 |
|---|---|
| x-bce-request-id | 对应请求的requestId |
请求结构说明
数据交换格式为JSON，所有request/response body内容均采用UTF-8编码。 请求参数包括如下4种：
| 参数类型 | 说明 |
|---|---|
| URI | 用于指明操作实体，如:PUT /v1/cluster/{clusterUuid} |
| Query参数 | URL中携带的请求参数 |
| HEADER | 通过HTTP头域传入，如:x-bce-date |
| RequestBody | 通过JSON格式组织的请求数据体 |
响应结构说明
响应值分为两种形式：
| 响应内容 | 说明 |
|---|---|
| HTTP STATUS CODE | 如200,400,403,404等 |
| ResponseBody | JSON格式组织的响应数据体 |
错误码
错误格式规范
当用户访问API出现错误时，会返回给用户相应的错误码和错误信息，便于定位问题，并做出适当的处理。请求发生错误时通过Response Body返回详细错误信息，遵循如下格式：
| 参数名 | 类型 | 说明 |
|---|---|---|
| code | String | 表示具体错误类型。 |
| message | String | 有关该错误的详细说明。 |
| requestId | String | 导致该错误的requestId。 |
示例
{
"code":"ProjectNotFound",
"message":"Project test_project is not found",
"requestId":" 81d0b05f-5ad4-1f22-8068-d5c9de60a1d7"
}公共错误码
业务错误码
| HTTP状态码 | 错误码（code） | 错误消息（message） | 中文描述 |
|---|---|---|---|
| 403 Forbidden | ProjectNoPermission | No permission to operate project {0} | 对项目{0}无操作权限 |
| 404 Not Found | ProjectNotFound | Project {0} is not found. | 项目{0}不存在。 |
| 403 Forbidden | WorkbenchNoPermission | No permission to operate workbench {0} | 对工作台草稿{0}无权限 |
| 400 Bad Request | InvalidCategory | Category {0} is invalid. | 不合法的作业种类 {0} |
| 400 Bad Request | InvalidWorkbenchName | Name of workbench {0} is invalid. | 草稿名称{0}不合法 |
| 400 Bad Request | DuplicatedWorkbenchName | Name of workbench {0} is duplicated. | 草稿名称{0}已存在 |
| 404 Not Found | WorkbenchNotFound | Workbench {0} is not found. | 草稿{0}不存在 |
| 400 Bad Request | InvalidDirectoryName | Name of directory {0} is invalid. | 文件夹名称{0}不合法 |
| 400 Bad Request | DuplicatedDirectoryName | Name of directory {0} is duplicated. | 文件夹名称{0}已存在 |
| 400 Bad Request | DirectoryIllegalDepth | A directory can contain a maximum of 5 levels. | 文件夹层级最多5层 |
| 404 Not Found | DirectoryNotFound | Directory {0} is not found | 文件夹 {0} 不存在。 |
| 403 Forbidden | JobNoPermission | No permission to operate job {0} | 对作业{0}无操作权限 |
| 404 Not Found | JobNotFound | Job {0} is not found. | 作业 {0} 不存在。 |
| 409 Conflict | JobAlreadyExists | Job {0} is already existed | 作业 {0} 已存在。 |
| 404 Not Found | ExecutionNotFound | Execution {0} is not found. | 实例 {0} 不存在。 |
| 409 Conflict | ExecutionIsRunning | Execution {0} is running. | 实例 {0} 已运行。 |
| 409 Conflict | ExecutionAlreadyStopped | Execution {0} was stopped. | 实例 {0} 已停止。 |
| 404 Not Found | SchedulerNotFound | schedule option is not found | 调度配置不存在 |
| 404 Not Found | ProfileNotFound | profile {0} is not found. | 资源 {0} 不存在 |
| 409 Conflict | ProfileIsUnavailable | profile {0} is unavailable. | 资源 {0} 不可用 |
版本号
| 参数 | 类型 | 参数位置 | 描述 | 是否必须 |
|---|---|---|---|---|
| version | String | URI参数 | API版本号 | 必须 |
日期和时间
日期与时间的表示有多种方式。为统一起见，除非是约定俗成或者有相应规范的，凡是HTTP标准中规定的表示日期和时间字段用GMT，其他日期时间表示的地方一律采用UTC时间，遵循ISO 8601，并做以下约束：
- 表示日期一律采用yyyy-MM-dd方式，例如2023-06-01表示2023年6月1日。
- 表示时间一律采用HH:mm:ss方式，并在最后加一个大写字母Z表示UTC时间。例如12:00:00Z表示UTC时间12点0分0秒。
- 凡涉及日期和时间合并表示时，在两者中间加大写字母T，例如2023-06-01T12:00:00Z表示UTC时间2023年6月1日21点0分0秒。
规范化字符串
通常一个字符串中可以包含任何Unicode字符。在编程中这种灵活性会带来不少困扰。因此引入“规范字符串”的概念。一个规范字符串只包含百分号编码字符以及URI（Uniform Resource Identifier）非保留字符（Unreserved Characters）。 RFC 3986规定URI非保留字符包括以下字符：字母（A-Z，a-z）、数字（0-9）、连字号（-）、点号（.）、下划线（_）、波浪线（~）。 将任意一个字符串转换为规范字符串的方式是:
- 将字符串转换成UTF-8编码的字节流。
- 保留所有URI非保留字符原样不变。
- 对其余字节做一次RFC 3986中规定的百分号编码（Percent-Encoding），即一个%后面跟着两个表示该字节值的十六进制字母。字母一律采用大写形式。 示例： 原字符串：this is an example for 测试, 对应的规范字符串：this%20is%20an%20example%20for%20%E6%B5%8B%E8%AF%95。 EDAP编码规范
EDAP编码规范
- 可解析内容，所有request/response body内容目前均使用UTF-8编码，后续会支持更多encoding类型。
-
在请求时，需要对以下做UrlEncode：
- Objectname，其中，Resource做UrlEncode的时候需要忽略“/”。
- Querystring的Value。
- x-bce-copy-source（忽略“/”）。
- 自定义Meta:Meta Value只支持可见的ASCII字符，如果需要其它的字符，推荐使用UrlEncode处理。
幂等性
详见幂等性