开发者社区> 问答> 正文

批量计算API调用方式有哪些?

批量计算API调用方式有哪些?

展开
收起
小天使爱美 2020-03-30 11:17:36 1286 0
1 条回答
写回答
取消 提交回答
  • 请求结构 发起 API 请求的 URL 由不同参数拼凑而成,有固定的请求结构。URL 中包含如下:

    服务地址 通讯协议 请求方法 公共头参数 每个 API 的特有参数 每篇 API 文档均给出了 URL 请求示例供您参考,我们并没有编码这些 URL 示例,您需要在发起请求前自行编码。如果你使用 SDK 来发起 API 请求,您只需要设置一些公共参数和 API 的具体参数,SDK 会自动会编码。 公共HTTP头定义 公共请求头 对于访问授权,BatchCompute 采用阿里云通用的签名方式,即请求头部包含特定以”x-acs”开头的字段,通过计算签名和比较签名进行用户验证。其中头部必须包含的字段如下:

    标准头 Header名称 类型 说明 Authorization 字符串 签名内容。该字段必选,它为非签名字段。参阅 签名机制 Content-Length 数字 Body 部分实际请求长度。如果传输是压缩格式,则为压缩后大小;如果请求不包含 Body,则数值为 0,它为非签名字段。 Content-MD5 字符串 Body 经过 MD5 计算后的字符串,计算结果为大写;如果没有 Body 部分,则不需要填写该请求头。 Content-Type 字符串 Body 类型。类型为字符串,分为 application/json 和 application/json-rpc 两种类型,默认值为 application/json;如果没有 Body 部分,则不需要填写该请求头。 Date 字符串 当前发送时刻的时间,参数目前只支持 RFC 822 格式,使用 GMT 标准时间。格式化字符串如下:%a, %d %b %Y %H:%M:%S GMT (如:Mon, 3 Jan 2010 08:33:47 GMT)。Date 所表示的时间与服务器接收到 request 的时间最大误差为 15 分钟。如果超过 15 分钟的时间误差则服务器端拒绝该请求。 Accept 字符串 客户端需要的返回值类型,支持 application/json 和application/json-rpc。默认值:无。 Host 字符串 请求 host 完整名字(不加 http:// ),例如:batchcompute.cn-qingdao.aliyuncs.com。 自定义头 Header名称 类型 说明 x-acs-version 字符串 当前 API 版本,目前版本为 2015-11-11 x-acs-compress-type 字符串 压缩方式。目前只支持 deflate,如果不压缩可以不填写该字段。 x-acs-body-rawsize 数字 Body 原始大小,当压缩时用以解压,当无 Body 时该字段为 0。范围为 0-256KB。 x-acs-signature-method 字符串 签名计算方式,目前支持“hmac-sha1”。 x-acs-signature-nonce 字符串 唯一随机数,用于防止网络重放攻击。用户在不同请求间,要使用不同的随机数值。 x-acs-access-id 字符串 用户访问 BatchCompute 的 AccessId,默认值:无。 x-acs-request-id 字符串 用户自动生成的请求 ID,以便日志跟踪。 示例 HTTP 头部格式如下:

    Authorization: acs [Access Key Id]:[Signature] Content-Length: 2324 contentMd5: 871bd77924e76fb320f2d13f55e8a7a2 Content-Type: application/json Date: Tue, 06 Nov 2018 06:12:40 GMT Accept: application/json Host: batchcompute.[Region].aliyuncs.com Accept-Encoding: identity User-Agent: Mozilla/5.0 (Windows NT 6.1) x-acs-version: 2015-11-11 x-acs-signature-method: HMAC-SHA1 x-acs-signature-nonce: f76e8ab8-e18a-11e8-bc78-645aede9015d x-acs-signature-version: 1.0 x-acs-access-key-id: [Access Key Id] x-acs-region-id: [Region] 返回结果 调用 API 服务后返回数据采用统一格式,具体包括:

    状态码 响应头 响应数据 成功结果 返回的 HTTP 状态码为 2xx,代表调用成功;

    响应数据格式为 JSON 格式,在每个 API 中有具体的描述响应数据的内容。

    以下是创建集群返回 成功的示例:

    HTTP/1.1 201 Created Date: Tue, 06 Nov 2018 06:12:41 GMT Content-Type: application/json; charset=utf-8 Content-Length: 35 Connection: close Access-Control-Allow-Origin: * Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Headers: X-Requested-With, X-Sequence, _aop_secret, _aop_signature Access-Control-Max-Age: 172800 x-acs-request-id: D874CC9A-C2D4-4DAE-A351-1699550F11A9 Server: AliyunBatchCompute {"Id":"cls-6ki3sg6sqlno7nt8fu0007"} 错误结果 返回的 HTTP 状态码为 4xx 或 5xx ,代表调用失败,具体状态码参考 公共错误码 以及各个 API 的错误码。

    返回的 Body 中包含 “Code” 和 “Message” 字段,您可以根据此信息来排查错误。

    响应头中的 x-acs-request-id 包含请求的 request id。当您无法排查错误时,可以提交工单联系我们,并在工单中注明 request id。

    以下是一个请求错误的示例:

    HTTP/1.1 400 Bad Request Date: Tue, 06 Nov 2018 08:30:40 GMT Content-Type: application/json; charset=utf-8 Content-Length: 90 Connection: close Access-Control-Allow-Origin: * Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Headers: X-Requested-With, X-Sequence, _aop_secret, _aop_signature Access-Control-Max-Age: 172800 x-acs-request-id: F067DAB7-57C4-4D08-BE49-CDB63BF5C6D2 Server: AliyunBatchCompute

    {"Code":"InvalidParameter.ImageId","Message":"Specified parameter ImageId is not valid. "}

    公共错误码 在对 BatchCompute API 进行访问时,不同请求可能会返回不同的错误码,如下是所有公共的错误码。

    状态码 错误码 错误信息 400 InvalidJsonFormat The request body has an invalid json format. 400 BadDAG It is a cyclic dag. 400 InvalidUrlPattern Specified url pattern contains some illegal words. 400 MethodNotAllowed The request http method is not supported for this resource. 400 Missing {Parameter Name} {Parameter Name} is mandatory for this action. 400 Invalid {Parameter Name} Specified parameter {Parameter Name} is not valid. {Message}. 400 IdempotentTokenMismatch Specified idempotent token mismatch. 403 InvalidVersion.NotFound Specified version is not found. 403 InvalidResource.AlreadyExisting Specified resource already exists. 403 InvalidQueryString {Message}. 403 InvalidHttpBody {Message}. 403 QuotaExhausted The {QuotaName} ({Value}) quota is exhausted. 403 Forbidden User not authorized to operate on the specified resource. 404 InvalidResource.NotFound Specified resource is not found. 409 StateConflict User operation is invalid. The current resource state is {State}. 500 InternalError The request processing has been failed due to some unknown error. 签名机制 BatchCompute 通过使用 Access Key ID/ Access Key Secret 方法来验证某个请求的发送者身份。Access Key ID 用于标示用户,Access Key Secret 是用户用于加密签名字符串和 BatchCompute 用来验证签名字符串的密钥,其中 Access Key Secret 必须保密,只有用户和 BatchCompute 知道。

    当用户想以个人身份向 BatchCompute 发送请求时,需要首先将发送的请求按照 BatchCompute 指定的格式生成签名字符串;然后使用 Access Key Secret 对签名字符串进行加密产生验证码。 BatchCompute 收到请求以后,会通过 Access Key ID 找到对应的 Access Key Secret,以同样的方法提取签名字符串和验证码,如果计算出来的验证码和提供的一样即认为该请求是有效的;否则,BatchCompute 将拒绝处理这次请求,并返回 HTTP 400 错误。

    用户可以在 HTTP 请求中增加 Authorization(授权)的 Head 来包含签名(Signature)信息,表明这个消息已被授权。

    Authorization 字段计算方法如下:

    Authorization: "acs " + Access Key Id + ":" + Signature Signature = base64(hmac-sha1(AccessKeySecret, + VERB + "\n" + ACCEPT + "\n" + CONTENT-MD5 + "\n" + CONTENT-TYPE + "\n" + DATE + "\n" + CanonicalizedBatchComputeHeaders + CanonicalizedResource)) AccessKeySecret 表示签名所需的秘钥 VERB 表示 HTTP 请求的 Method,主要有 PUT,GET,POST,HEAD,DELETE 等(大写) CONTENT-MD5 表示请求内容数据的 MD5 值,详情参看(十六进制序列,字母小写) ACCEPT 表示 HTTP 请求期望接受的类型 CONTENT-TYPE 表示请求内容的类型 DATE 表示此次操作的时间,且必须为 HTTP1.1 中支持的 GMT 格式 CanonicalizedOSSHeaders 表示以“x-acs-”为前缀的 http header 的组合 CanonicalizedResource 表示 API 想要访问的 BatchCompute 资源 其中,CanonicalizedBatchComputeHeaders 表示 http 中的 object meta 组合。CanonicalizedResource 表示 API 想要访问的 BatchCompute 资源。DATE 和 CanonicalizedResource 不能为空。如果请求中的 DATE 时间和 BatchCompute 服务器的时间差正负 15 分钟以上,BatchCompute 服务器将拒绝该服务,并返回 HTTP 400 错误。其他字段请参考公共请求头参数。

    构建 CanonicalizedBatchComputeHeaders 的方法:

    所有以“x-acs-”为前缀的 HTTP Header 被称为 CanonicalizedBatchComputeHeaders,它的构建方法如下:

    将所有以“x-acs-”为前缀的 HTTP 请求头的名字转换成小写字母。如“X-Acs-Meta-Name: TaoBao”转换成“x-acs-meta-name: TaoBao”; 将上一步得到的所有 HTTP 请求头按照字典序进行升序排列; 如果有相同名字的请求头,则根据标准 RFC 2616, 4.2 章进行合并(两个值之间只用逗号分隔)。如有两个名为“x-acs-meta-name”的请求头,对应的值分别为“TaoBao”和“Alipay”,则合并后为:“x-acs-meta-name:TaoBao,Alipay”; 删除请求头和内容之间分隔符两端出现的任何空格。如“x-acs-meta-name: TaoBao,Alipay”转换成:“x-acs-meta-name:TaoBao,Alipay”; 将所有的头和内容用“\n”分隔符分隔拼成最后的CanonicalizedBatchComputeHeader。 构建CanonicalizedResource的方法:

    用户发送请求中想访问的 BatchCompute 目标资源被称为 CanonicalizedResource。它的构建方法如下:

    将 CanonicalizedResource 置成空字符串(“”); 放入要访问的 BatchCompute 资源:“/ResourceName/ResourceId”(无 ResourceId 则不填); 如果请求的资源包括子资源(sub-resource) ,那么将所有的子资源按照字典序,从小到大排列并以“&”为分隔符生成子资源字符串。在 CanonicalizedResource 字符串尾添加“?”和子资源字符串。此时的 CanonicalizedResource 例子如:/jobs/(id)/tasks?Marker=(Marer)&MaxItemCount=(MaxItemCount)。 例如,需要签名以下信息:

    PUT /jobs/job-000000005645B53B0000AEA300000001 HTTP/1.0 Content-Md5: 900150983cd24fb0d6963f7d28e17f72 Content-Type: application/json Date: Thu, 17 Nov 2005 18:49:58 GMT Host: batchcompute.cn-qingdao.aliyuncs.com x-acs-signature-method: HMAC-SHA1 x-acs-signature-version: 1.0 其中,Access Key ID 是:“44CF9590006BF252F707”, Access Key Secret 是“OtxrzxIsfpFjA7SwPzILwy8Bw21TLhquhboDYROV”,可用以下方法签名(Signature):

    python示例代码:

    import base64 import hmac import sha h = hmac.new("OtxrzxIsfpFjA7SwPzILwy8Bw21TLhquhboDYROV", "PUT\n900150983cd24fb0d6963f7d28e17f72\napplication/json\nThu, 17 Nov 2005 18:49:58 GMT\nx-acs-signature-method:HMAC-SHA1\nx-acs-signature-version:1.0\n/jobs/job-000000005645B53B0000AEA300000001", sha) base64.encodestring(h.digest()).strip() 签名(Signature)计算结果应该为“26NBxoKdsyly4EDv6inkoDft/yA=”, 然后加上 Authorization 头来组成最后需要发送的消息:

    PUT /jobs/job-000000005645B53B0000AEA300000001 HTTP/1.0 Authorization: acs 44CF9590006BF252F707: 26NBxoKdsyly4EDv6inkoDft/yA= Content-Md5: 900150983cd24fb0d6963f7d28e17f72 Content-Type: application/json Date: Thu, 17 Nov 2005 18:49:58 GMT Host: batchcompute.cn-qingdao.aliyuncs.com x-acs-signature-method: HMAC-SHA1 x-acs-signature-version: 1.0 在计算签名头的时候请遵循如下规则:

    用来签名的字符串必须为 UTF-8 格式。含有中文字符的签名字符串必须先进 UTF-8 编码,再与 Access Key Secret 计算最终签名。 签名的方法用 RFC 2104 中定义的 HMAC-SHA1 方法,其中 Key 为 Access Key Secret。 Content-Type 和 Content-MD5 在请求中不是必须的,但是如果请求需要签名验证,空值的话以换行符“\n”代替。 在所有非 HTTP 标准定义的 header 中,只有以“x-acs-”开头的 header,需要加入签名字符串;其他非 HTTP 标准 header 将被忽略。 以“x-acs-”开头的 head 在签名验证前需要符合以下规范: head 的名字需要变成小写。 head 按字典序自小到大排序。 分割 head name 和 value 的冒号前后不能有空格。 每个Head之后都有一个换行符“\n”,如果没有 Head,CanonicalizedBatchComputeHeaders 就设置为空。 备注:BatchCompute 所有的请求都必须使用 HTTP 1.1 协议规定的 GMT 时间格式 。其中,日期的格式有三种:

    date1 = 2DIGIT SP month SP 4DIGIT; day month year (e.g., 02 Jun 1982) date2 = 2DIGIT “-“ month “-“ 2DIGIT; day-month-year (e.g., 02-Jun-82) date3 = month SP ( 2DIGIT or ( SP 1DIGIT )); month day (e.g., Jun 2) 【注意“2”前面有两个空格】 述这三种日期格式中,“天”所占位数都是“2 DIGIT”。因此,“Jun 2”、“2 Jun 1982”和“2-Jun-82”都是非法日期格式。

    2020-03-30 11:47:50
    赞同 展开评论 打赏
问答分类:
问答地址:
问答排行榜
最热
最新

相关电子书

更多
CUDA MATH API 立即下载
API PLAYBOOK 立即下载
传统企业的“+互联网”-API服务在京东方的实践 立即下载