admin管理员组

文章数量:1531663

2024年1月4日发(作者:)

淘宝网

开放平台错误自查手册

本文档针对2.0服务,1.0请酌情参考

2010-11-8

杭州

开放平台错误自查手册

目录

一、

错误处理流程概览 .................................................................................................... 2

二、

服务器响应内容透析 ................................................................................................ 3

1.

调用成功返回格式 ....................................................................................................... 4

2.

调用错误返回 ............................................................................................................... 4

1)

http连接错误 ............................................................................................................ 4

2)

服务端错误总述 ........................................................................................................ 4

3)

平台解析错误 ............................................................................................................ 5

4)

业务处理错误 ............................................................................................................ 6

三、

响应格式错误处理 .................................................................................................. 10

1.

响应格式格式错误,但数据正确 ............................................................................. 11

2.

响应格式错误,数据也错误 ..................................................................................... 12

四、

平台级错误处理 ...................................................................................................... 12

五、

业务级错误处理 ...................................................................................................... 14

1.

参数错误 ..................................................................................................................... 14

2.

权限控制 ..................................................................................................................... 15

3.

用户不存在 ................................................................................................................. 15

4.

服务错误 ..................................................................................................................... 16

a)

服务调用错误 .......................................................................................................... 16

b)

服务调用异常 .......................................................................................................... 17

c)

远程调用错误 .......................................................................................................... 17

d)

Top解析错误 .......................................................................................................... 17

六、

返回参数缺失处理 .................................................................................................. 17

1.

整个消息体为空或缺少文档中说明的结构体返回。 ............................................. 17

2.

缺少fields指定字段返回........................................................................................... 18

七、

总结 .......................................................................................................................... 18

一、 错误处理流程概览

2

开放平台错误自查手册

从这个错误处理流程可知,在整个错误处理的过程中,一共可以分为3条主要的流程:请求解析异常流程处理,平台级错误处理和业务调用错误处理。当然,这一切处理的最初也是最重要的一步就是:将服务器响应内容保留下来。

二、 服务器响应内容透析

服务器响应内容,顾名思义就是isv调用top服务得到的响应的内容。这些内容能够最真实的反应出isv请求的问题和服务器当前的情况,也最能够帮助isv找到问题的所在。

服务器响应内容一般分为两种:一种是wiki文档中所编写的成功调用所返回的字段,

3

开放平台错误自查手册

另一种是调用失败的返回的错误相关信息。

1. 调用成功返回格式

调用成功的响应信息内容根据调用服务版本的不同分为了两种不同的格式。

1.0的服务返回信息的格式分为三层:最外一层是"rsp":{ }标记,表示这是服务的响应内容;中间一层是返回结构体的标记,如:返回的是商品的结构体,中间这层就是"items":[{ },{ }……],表示结果是一个商品的列表,如果返回参数不是以结构体的形式,这一层就不存在;最内一层就是每个结构体具体的字段了。1.0这个版本所有返回结果,不论是单个的商品还是一个商品列表,他的第二层都是一个列表的结构,区别只是列表里有一个子结构体还是有多个子结构体而已。

相比之下,2.0的服务返回信息就相对的规范化了。2.0的响应内容主要也可以分为3层:最外一层是你调用服务的名称所对应的响应标记,如:获取单个商品()的响应最外层为"item_get_response":{ },表示这是获取单个商品的响应;中间一层是返回结构体的标记。如果结构体是单个,那么2.0返回的这一层里面就会是单个的结构,如:获取的单个商品的结构体就是"item":{ };反之,如果结构体是多个,那么列表也会明显的表示出来,如:搜索商品列表的结构体就会是”items”:{“item”:[{ },{ }……]}。最外层的items表示这是一个商品的列表,后面的item表示列表中的每一个子结构体都是属于商品item的,然后就跟着商品的数据;最内一层就商品的具体字段信息了。

2. 调用错误返回

当调用发生错误的时候,一般情况下可以分为几大类错误信息的返回:http连接错误、平台解析错误、业务处理错误。这三种类型的错误分别代表了:淘宝服务器、淘宝接入平台、top-api业务,几个层次上出现的问题。

1) http连接错误

http连接错误是请求通信过程中出现的错误,这类型错误通常由http响应码标记出来。http响应码由三位十进制数字组成,它们出现在由HTTP服务器发送的响应的第一行。

响应码分五种类型,由它们的第一位数字表示:

1xx:信息,请求收到,继续处理

2xx:成功,行为被成功地接受、理解和采纳

3xx:重定向,为了完成请求,必须进一步执行的动作

4xx:客户端错误,请求包含语法错误或者请求无法实现

5xx:服务器错误,服务器不能实现一种明显无效的请求

Isv调用top服务最常收到就是200:http请求成功;404:未找到请求的服务;500内部服务器错误等等。如果用户收到的响应码是404,表示用户的网络有问题或者top被和谐了……如果用户收到的响应码是500,表示网络是ok的,是top的服务无法响应。

2) 服务端错误总述

平台解析错误和业务处理错误都是http成功访问到top服务(http响应码返回为200)之后所产生的错信息,他们top处理isv请求过程中出现的问题。1.0和2.0的格式有所不同。1.0的错误响应信息最外层为{“error_rsp”:{ }},表示这是调用错误所返回的信息。里面一层包含两个元素:”code”:” ”和 “msg”:” ”,前者表示错误码是多少,后者表示错误信息是什

4

开放平台错误自查手册

么。例如错误的调用1.0的服务错误时返回的错误信息:

{"error_rsp":{"code":40,"msg":"Missing required arguments:missing parameter iid/num_iid"}}。

这个信息的开头为error_rsp,表示这是调用错误所返回的结果。里面包含的错误体的code为40,是平台型错误,表示错误是缺少了必传参数所引起的。然后msg内容为Missing required

arguments:missing parameter iid/num_iid,表示缺少的必传参数是iid或者num_iid。Isv解析到这些信息后就需要根据错误信息改进自己传入的参数来使调用成功。

2.0的错误响应信息的最外层为{“error_response”:” ”},表示这是调用服务失败所返回的错误信息。信息体里面一层总共包含了五个元素:"args":{"arg":[{“key”:“ ”,”value”:” ”},{“key”:“ ”,”value”:” ”},{“key”:“ ”,”value”:” ”}……]},”code”:”

”, “msg”:” ”,”sub_code”:” ”和”sub_msg”:” ”。args表示用户传入的参数列表是什么,里面是一个arg的列表会包含用户传入的所有参数信息,每个arg表示一个参数的信息,key表示参数的名称,value表示参数的内容,用以方便用户定位自己的错误;code表示用户调用错误的错误码是多少,小于200表示平台级错误,200-1000之间表示大范围的业务错误,即哪一类型的api调用发生了错误(根据api的大类来分,如:商品类的api是530,交易类的api是520,等);msg表示大类型的错误码所对应的错误信息,一般不具备独立的debug作用,需要和sub_code和sub_msg一起使用才行;sub_code是调用错误的子错误码,他表示用户调用错误的原因;sub_msg是子错误码所对应的错误信息,他用来补充细化子错误码的错误原因的。例如调用2.0的服务错误时返回的错误信息:

{"error_response":{"args":{"arg":[{"key":"app_key","value":"15739"},{"key":"fields","value":"list_time,delist_time,approve_status"},{"key":"format","value":"json"},{"key":"method","value":""},{"key":"nick","value":"tbtest561"},{"key":"partner_id","value":"TOPTEST"},{"key":"sign","value":"668FB4A049F71A1C845EF8C05B1F3E66"},{"key":"timestamp","value":"2010-03-05

18:03:06.325"},{"key":"v","value":"2.0"}]},"code":530,"msg":"Remote service

error","sub_code":"missing-parameter","sub_msg":"iid和num_iid至少要传入一个"}}

这个信息的开头为error_response,表示这是调用错误所返回的错误信息。里面的args列出了用调用这个接口传入的信息有:[{"key":"app_key","value":"15739"},{"key":"fields","value":"list_time,delist_time,approve_status"},{"key":"format","value":"json"},{"key":"method","value":""},{"key":"nick","value":"tbtest561"},{"key":"partner_id","value":"TOPTEST"},{"key":"sign","value":"668FB4A049F71A1C845EF8C05B1F3E66"},{"key":"timestamp","value":"2010-03-05

18:03:06.325"},{"key":"v","value":"2.0"}],这些信息是从用户的请求信息里面解析出来的。错误码code为530,表示这是调用商品的api所产生的错误。错误信息msg为Remote service error表示这是调用业务处理所产生的错误。子错误码sub_code为:missing-parameter,表示这个错误是因为缺少了参数所产生的。子错误信息sub_msg为:iid和num_iid至少要传入一个,表示少传的参数为iid或num_iid。这所有的错误信息叠加起来可以知道,这个错误是用户调用接口时业务处理发现用户没有传入商品id所导致的。

3) 平台解析错误

平台解析错误是指top返回的错误码小于100的情况。平台解析是非业务性的普适的校验接入层,主要用于对用户的各种权限、和入参进行最基本的校验。现在的平台错误码主要有:

5

开放平台错误自查手册

Isv可以通过错误码和解释来纠正问题。如:错误码为3的响应表示图片上传失败,错误码为26表示用户没有传入session参数,错误码为27表示用户传入的session参数找不到对应的session记录,等等。

4) 业务处理错误

业务处理错误是用户通过平台校验进入业务流程出现了错误所发出来的。这一层的错误

6

开放平台错误自查手册

码根据调用版本不同分为两种。如果版本是1.0,那么返回的错误信息格式就是:{“error_rsp”:{“code”:XXX,”msg”:”……”}},里面的code是数字形式的标记着一种错误的编码,msg是字符串形式,标记在错误的具体信息。如,获取当商品失败的错误信息就是:{"error_rsp":{"code":551,"msg":"Item service unavailable:获取单个商品失败"}}。1.0的错误码有以下几种:

7

开放平台错误自查手册

8

开放平台错误自查手册

1.0的返回的错误code就是其中的错误码,错误msg就是其中的英文错误描述加上具体的错误信息组成的。

如果版本是2.0,那么服务器所返回的错误信息格式就是:{“error_response”:{"args":{"arg":[{“key”:“ ”,”value”:” ”},{“key”:“ ”,”value”:” ”},{“key”:“ ”,”value”:”

”}……]},”code”:” ”,“msg”:” ”,”sub_code”:” ”,”sub_msg”:” ”}},里面的code是数字形式的标记着一种业务类型的错误编码,msg则是比较大范围内的表示错误类型的字符串。而sub_code是以字符串形式粗略表示错误的类型,sub_msg则是表示具体的错误原因。2.0的code包含以下几种分类:

产品线 错误码

用户

500

类目

510

交易

520

退款

521

商品

530

商品扩展API

531

邮费模板

532

产品

540

物流

550

店铺

560

评价

570

淘宝客

580

系统

590

备案

591

9

开放平台错误自查手册

增量API

600

比价

610

画报

620

江湖

630

分销

640

淘秀

650

收费

660

Misc(保证金等杂项api)

670

由上图可知,每一大类的api在2.0中其实是共享一个code的,它能让用户在复杂组合调用中指导是哪一类的api出现了问题,实现初步的定位。

2.0的业务错误中,msg里面最容易出现的内容就是Remote service error,这表示用户是在通过了平台校验后进行业务流程的时候出现的错误。其他的错误还有Remote Service

Timeout:后台处理业务超时等等的错误。这一个错误信息的力度比较粗,很难单独用她进行错误处理。2.0的业务处理错误信息主要要看sub_code和sub_msg这连个字段。sub_code表示了服务费对业务错误的分类,sub_msg表示了是错误原因。

Sub_code根据业务错误类型主要可以分为如下几类

子错误码 错误归类

user-not-exist

用户不存在

missing-parameter

缺少参数

invalid-parameter

参数错误

parameters-mismatch

参数不匹配(主要针对那些需要一一对应的入参)

Invalid-permission

权限不足

remote-service-error

调用后端服务错误

remote-service-timeout

调用后端服务超时

remote-connection-error

调用后端服务连接错误

XXX-service-unavailable

调用后端服务失败

item-extra-not-exist

商品扩展信息不存在

trade-not-exist

交易记录不存在

refund-not-exist

退款记录不存在

每一类的子错误码代表着某一类型的错误,例如user-not-exist表示用户传入的nick或者用户绑定的session所对应的nick找不到对应的用户记录,Invalid-permission表示用户由于权限问题不能进行某些操作。sub_code给予isv或用户以改进错误的方向,而sub_msg则告诉用户改进点。例如sub_code为invalid-parameter,sub_msg为用户传入的iid不能超过40个,这就表示着,这次错误的原因是用户传入的参数iid由于数量超过40个而产生了错误。

错误响应时用户和服务器交互失败的最直接展示,isv在调用top服务时,如果调用失败,请尽量保留下错误信息(建议尽量改用2.0调用,这个版本的错误信息比较全面),以便进行后面的错误追查。

三、 响应格式错误处理

响应格式错误是指用户调用top服务时,传入参数设置了format参数为json,但是接受到的却为xml的响应格式,或者设置格式为xml接收到的却为json响应的格式的情况。一般正常情况下这种情况是不会出现的,但是还是会有一些异常的情况会引起这个问题。这种响应格式错误的问题在isv的程序中通常会表现为,响应解析格式错误。例如:用户使用

10

开放平台错误自查手册

的top的java SDK客户端调用top服务,设置的format格式为json却得到了一个xml的响应,这是sdk就会报一个错误说响应开始处缺少一个“{”符号。这是因为xml响应是以“<”开始的缘故。

一般会发生这种现象的原因有一下三种:用户传入的参数过大导致流解析异常,用户调用太过频繁道士响应异常,top服务器故障。

为了定位到问题出在哪里,以便找到相应的解决方法,用户在遇到响应格式错误的情况时可以参考以下步骤进行调试。

1. 响应格式格式错误,但数据正确

用户第一步应该分析一下相应的内容里面是不是除了格式错误以外,其他的响应内容都是正确调用的返回结果。

例如,有个用户用top的sdk,设置format为json,调用top得到了这样一个返回结果:

11

开放平台错误自查手册

ception: A JSONObject text must begin with '{' at character 1

1115

2010-03-01 16:04:15

2010-03-01 16:04:05

2010-03-01 16:03:59

2010-03-01 16:03:53

……

2010-03-01 07:30:52

从这个异常的开头可以看到,这是sdk的json解析抛了一个异常,说响应内容的内容应该是以“{”开始的。这说名,isv收到的响应格式肯定出了问题。

再看一下响应的内容相应结果标签之间包含了totalResults和item列表,这些数据表明,这是调用商品查询接口返回的结果数据:查询到的结果总数是1115条,当前页的商品iid和最近修改时间也在其中。这些查询结果数据是正常的,但是返回格式却不是传入的json而是变成了xml。这位isv联系了top的技术支持,在建议减缓调用频率以后,返回的数据格式正常了,这样就临时控制了这种情况的发生。同时技术支持将这些情况反映到了开发,top这边后续就会找到问题根源,进一步杜绝这种情况的发生。

2. 响应格式错误,数据也错误

如果用户第一步分析发现,返回的信息并不是调用成功的信息而是某个平台错误,而且用户本身的参数并不会导致这个错误的产生,此时用户就需要查看自己调用接口的参数了。如果用户调用的接口需要传入比较大的数据(如:图片、商品的长篇描述等等),那么用户应首先尝试着减小这些入参到合法范围内输入(传入小图片或者之传入少量的描述文字等)。如果用户调用成功,表示错误是因为用户入参太大造成了解析错误引起的,用户应配合自己所在地方的网速,请求大小等等的信息合理设置自己的参数大小和接口调用顺序。

如果用户减小参数还是解析失败的话,用户尝试着不传入图片或只传入几个字节的描述的内容进行接口调用。在传入描述只有很少的字节的情况下:如果不传图片调用成功了,那么应该是top的服务器的问题,请将这个情况反馈给技术支持进行解决;如果图片不传调用仍然失败了,那么应该是用户的调用参数或网络有问题,请仔细对照文档说明对参数进行修改或等待网络状态好一点的时候进行调用。

总的来说,如果用户发生了响应格式错误的情况,一般分为三种情况:用户本身传入的format就是错误的,这种情况用户需要查看自己传入的参数是否正确;用户通信的网络太差,服务端造成请求解析失败而丢失了format信息,这种情况下用户需要调整自己的网络通信情况,等状况恢复再调用;如果是其他由于图片或调用太频繁而引起的问题,用户需要减小图片或减缓调用来提高成功率,并且将这些情况通报给top技术支持的同学。

四、 平台级错误处理

在前文的错误综述中介绍过,top的错误可以分为平台级错误和业务级错误。所谓平台

12

开放平台错误自查手册

级错误就是指:错误码小于100的调用错误。这种错误一般是由于用户的请求不符合各种的基本校验而引起的。下面将对于各种平台级错误及相应的解决办法陈列于此。

错误码 错误解释 解决办法

3

图片上传失败 将传入的图片格式改为正确的格式、适当的大小的图片放进消息体里面传输过来。如果传输仍然失败需要减小图片大小或者增加网络带宽进行尝试

4

用户调用次数超限 调整程序逻辑合理利用api,等第二天再调用。或5

会话调用次数超限 者向技术运维的同学申请增加调用次数

6

合作伙伴调用次数超限

7

应用调用次数超限

8

应用调用频率超限 Isv调节api调用频率,不能太过频繁的调用

9

HTTP方法被禁止 请用大写的POST或GET,如果有图片等信息传入则一定要用POST才可以

10

服务不可用 多数是由未知异常引起的,用户仔细检查自己传入的参数是否符合文档中描述的样子

11

开发者权限不足 appKey所对应的应用不具备权限调用当前接口。12

用户权限不足 需要联系运营或技术支持的同学开通调用该接口13

合作伙伴权限不足 的权限。

15

远程服务出错 Api调用后端服务出错,isv首先查看自己的参数是否合法,如果参数没有问题请过一段时间再尝试,如果还不行请联系技术支持

21

缺少方法名参数 传入的参数加入method字段

22

不存在的方法名 传入的method字段必需是你所调用的api的名称,并且该api是确实存在的

23

非法数据格式 传入的format必需为json或xml中的一种

24

缺少签名参数 传入的参数中必需包含sign字段

25

非法签名 签名必需根据正确的算法算出来的。算法请见:

/dev//API签名算法

26

缺少SessionKey参数 传入的参数中必需包含session字段

27

非法的SessionKey参数 传入的session必需是用户绑定session拿到的。如果报session不合法可能是用户没有绑定session或session过期造成的,用户需要重新绑定一下然后传入新的sessionKey。

28

缺少AppKey参数 传入的参数必需包含app_key字段

29

非法的AppKey参数 用户传入的appKey参数确实是要存在的,如果没有申请appKey的同学请去申请appKey,如果是已经有了appKey却调用不同过的,请联系技术支持解决

30

缺少时间戳参数 传入的参数中必需包含timestamp参数

31

非法的时间戳参数 用户传入的时间戳不合法。时间戳,格式为yyyy-mm-dd hh:mm:ss,例如:2008-01-25 20:23:30。淘宝API服务端允许客户端请求时间误差为10分

13

开放平台错误自查手册

钟。

32

缺少版本参数 传入的参数中必需包含v字段

33

非法的版本参数 用户传入的版本号格式错误,必需为数字格式

34

不支持的版本号 用户传入的版本号没有被提供。现在top只支持1.0或2.0两种版本

40

缺少必选参数 用户传入的参数中漏掉了必传的参数。请仔细对照文档检查

41

非法的参数 用户传入的参数不符合文档中说明的参数格式,请参照文档进行修改

42

请求被禁止 请求 被禁止(目前没有在控制)

43

参数错误 参数解析发生错误或异常。一般是用户传入参数非法引起的。请仔细检查入参格式、范围、是否一一对应等等情况。

44

Isp error后台接入服务错误 这种后台服务异常引起的错误,请联系技术支持。

基本上来说,平台错误是一个通用的、普适的校验。一般针对用户的权限、安全、流量和最基本的参数等等进行校验。用户遇到这些错误的返回一定要第一步检查自己的权限、频率等情况;然后就需要参照文档检验一下自己的传入的参数是否完整且合法;如果这些都无法解决问题,请联系技术支持的同学进行反馈,top后台会尽快解决这些问题。

五、 业务级错误处理

业务级错误是指isv请求进入top业务处理以后爆出来的业务相关的错误,通常错误码分部在500-1000之间。Top的业务错误一般可以分为4个大类:参数错误、权限控制、用户不存在和服务错误。

1. 参数错误

参数错误指topapi根据业务要求对用户传入的参数进行校验组装的时候产生的错误。

1.0中的参数错误码有: 505,"Missing Parameters";506,"Parameters error";507,"Parameters

Format error"和XXX,”XXX not exist”(这里XXX表示未知的数字或字符串)等等。其中:505表示缺少传入某些需要传入的参数(如:获取sku列表的时候要求至少传入一个iid,isv却什么都没有传入);506表示传入的参数错误(如:传入的iid找到对应的商品已删除、传入的类目不存在等等);507表示用户传入的参数的格式不符合规定(如:需要传入数字的参数用户传入了非数字的字符);XXX not exist表示根据用户指定的参数(如:iid、tid等数据)找不到对应的记录,等等。

2.0中的参数错误的错误码是在调用返回的sub_code子错误码里面得到具体体现的。2.0的参数错误一般有如下几个错误码:missing-parameter,invalid-parameter,parameters-mismatch,XXX-not-exist等等。这几种错误分别表示:missing-parameter表示缺少了某些必传参数(如:获取单个商品是iid和num_iid一个都没传入);invalid-parameter表示用户传入的参数错误(如:传入的iids个数不符合规定,传入的iid对应的商品已删除等等);parameters-mismatch表示用户传入的某些有对应关系的参数个数不匹配了(如:input_pids和input_str长度不匹配,或者sku_properties和sku的其他参数个数不匹配);XXX-not-exist表示用户指定的参数找不到对应的记录(即这个参数所对应的记录不存在或已经被删除了)。

不管是1.0还是2.0的参数错误,都是由于isv传入的参数有问题而引起的。用户在遇到报参数错误的情况下,需要查看对应的错误消息内容(1.0就是msg,2.0是sub_msg)中

14

开放平台错误自查手册

的说明来进行入参修改。建议将这部分内容展示给用户,可以让用直观的看到错误的原因,从而改进输入。

2. 权限控制

权限控制的错误是指用户使用了自己不享有的服务所造成的错误。这类型的错误:1.0的错误码为:509,"Permission limited";2.0的子错误码为:invalid-permission。这类型的错误通常都是用户进行的操作触碰到了淘宝的业务规则,导致了top的业务校验不通过。如:用户没有登录却要获取某个卖家仓库中的商品,用户不享有多图服务却要上传商品多图或商品属性图片,成人类目直接上传图片,修改自动发货的商品,不是卖家或买家却要获取交易详细信息的……这些错误并不是用户传入的参数找不到相应的数据、或者传入的参数是错误的造成的。相反的,用户传入的参数都符合文档描述,但是用户不具备权限来进行相应的操作。

在这种情况下,isv有几条路可以选择。第一:对于查询类型的权限控制:如果用户是信息的所有者,那么需要让用户进行登录绑定,这样用户就够进行权限控制的操作了;如果用户不是信息的合法查看人,那么isv要明确的告诉用户这个操作不可以进行,并且不要进行重试操作了。第二:对于增删改类型的操作的权限控制:如果用户是因为没有享有服务(如:没有享有图片空间的服务)而产生的权限限制,isv需要引导用户去进行服务的开通后再来进行操作,之后再重新调用接口;如果是因为用户操作了别人的数据而引起的权限控制,那么isv要明确的跟用户报错,并且不能再进行重试操作。

总之,当用户遇到报权限控制的错误时,isv不能直接进行重试。应该将问题直接告诉用户,并引导用户进行相关的登录、开通服务等操作来调整权限以后,再让用户重试操作。如果用户不愿意进行调整,isv此时应该直接停止该操作,不能默认的进行重试,因为这种前提下,重试是完全没有作用的。

3. 用户不存在

用户不存在是指top后台根据用户绑定的nick或者传入的nick对用户信息进行查询的时候找不到用户记录所报出的错误。1.0的错误码:601, "User not exist";2.0的子错误码:user-not-exist。

用户遇到这种问题首先请确认调用的这个接口自己有没有传入nick这个参数。如果nick是根据用户绑定的session取得的,那么用户需要过一会儿再重新调用看看。如果隔一段时间还不行,请联系技术支持解决。

如果用户自己通过参数传入了nick,那么请用户仔细检查自己传入的nick是否正确。例如:有没有多一个空格或者大小写错误的?该用户是否确实存在的?等等。如果问题是因为名称错误或用户确实不存在引起,用户需要更改输入参数后才能再次调用。

如果用户名称正确,用户也确实存在,却还是报用户不存在错误,用户需要检查传入的nick是否包含难以识别的编码的字体。如果nick中包含了火星文或者其他编码的字体,请考虑将nick转换成utf8以后重新尝试或者放弃此次操作。

如果上述问题都不存在,请联系技术支持的同学进行查看。

整个查错过程如下所示:

15

开放平台错误自查手册

4. 服务错误

服务错误主要指用户的请求通过了api业务的基本校验,在调用后台服务的时候由于出现了异常或者更进步的业务报错而产生的错误。这一类错误主要分为3个大类:服务调用错误、服务调用异常、远程调用错误、top解析错误。

a) 服务调用错误

服务调用错误,是指通过top校验进入后端调用服务以后,由于不符合进一步的业务逻辑校验而出现的错误。如:发布商品的属性不符合商品类目的要求,评价的交易已经过期等等。这些错误在1.0的错误返回错误码为:XXX,”XXX service error”,在2.0的返回子错误码为:XXX-service-error。

16

开放平台错误自查手册

用户遇到这种返回表明top的服务是正常的,是用户的参数不合规定所引起。请根据返回的具体msg和sub_msg内容定位问题,然后改正入参后再调用。如果确认参数错误却一直通不过调用,请联系技术支持的同学咨询情况,切勿盲目重试。

b) 服务调用异常

服务调用异常是指服务调用过程中由于后端服务器没有响应或者产生了异常或者top服务本身产生了未被捕获的异常而产生的错误。这些错误在1.0的错误返回错误码为:XXX,”XXX service unavailable”,在2.0的返回子错误码为:XXX-service-unavailable。

这种错误有可能是后端服务暂时不可用所引起的,所以用户遇到这种错误时首先应该查看返回的错误信息里面有没有有效的提示信息,如果有请先按照提示改正问题再调用;如果没有有效的提示信息,请等待一段时间再调用。如果一直都是这个错误,请联系技术支持查看问题所在。切忌立即反复重试。

c) 远程调用错误

远程调用错误是指top在调用后方服务时发生了调用错误或超时的情况。这类错误可能是由于后端服务过于繁忙或者服务失效引起的。这些错误在1.0的错误返回错误码为:900,"Remote Connection Error",901,"Remote Service Timeout",902,"Remote Service Error",在2.0的返回子错误码为:remote-service-error,remote-service-timeout,remote-connection-error。

用户遇到这种情况,首先考虑的是等待一段时间重试看服务是否恢复。如果服务已经恢复,则这个只是短时间服务过于拥挤造成的;如果多次重试仍然是不可用,那么这个可能是后端服务出了问题,请联系技术支持进行处理。

d) Top解析错误

Top解析错误目前主要针对的是用户调用top服务时产生的未被捕获的空指针或者参数转换异常所产生的错误。这些错误是由于用户的请求有错误引发了top本身的服务流程的潜在隐患所引起的。1.0的错误返回错误码为:510,"Top parse error",在2.0的返回子错误码为:top-parse-error。

用户遇到这种问题时,请先仔细检查自己的参数,根据文档说明修改完善以后再尝试调用,一般正常情况,只要入参合法是能够成功的。如果确定参数正确的前提下还是调用报这个错误,请联系技术支持的同学反馈这个问题。

六、 返回参数缺失处理

返回参数缺失是指用户调用api返回成功,但是消息体里面的内容和所请求的内容不一致的情况。这种情况细分可以分为三种情况:整个消息体为空、消息体缺少文档定义的结构返回、返回的结构体中缺少fields指定的某些字段的返回。

1. 整个消息体为空或缺少文档中说明的结构体返回。

整个消息体为空或缺少文档中说明的结构体是指:返回结果是非失败的情况下,得到的Response的body内容和文档定义不一致(比文档写到要缺少某些内容)的情况。例如:调用新增商品接口,正常的返回结果1.0是:{"rsp":{"items":[{"created":"2009-11-17

16:30:50","iid":"cbf8d5d64b3fc80b25d21b1e1c88fd41"}]}}。2.0的返回结果是:{"item_add_response":{"item":{"iid":"699e0a75fcea3966d1d57fc8278c674b","created":"2009-10-22 15:08:42"}}}。根据文档的说明:添加商品成功的返回结构体中包含的数据就是这样。

17

开放平台错误自查手册

以此种返回结果举例,整个消息体为空的情况是指返回的结果为:{ }或{"item_add_response": }。这个消息体里面什么东西都没有,既没有报错的信息,也没有成功响应的数据在里面。如果遇到此种情况,并且这个情况是在某种条件下课重复出现的,这表示top后端服务的流程出现了异常流程,请尽快联系top的技术支持反馈问题。

缺少文档中说明的结构体,以上述添加商品的2.0服务的例子来说,返回回来的结构可能就是:{"item_add_response":{"item":{"iid":"699e0a75fcea3966d1d57fc8278c674b"}}}、{"item_add_response":{"item":{"created":"2009-10-22 15:08:42"}}}、{"item_add_response":{"item":{ }}}……等等情况。如果用户遭遇了这个情况,并且这种情况是可重复出现的,并且切换参数也还是这样,这说明top的调用成功了,但是服务器返回的数据出现了不正常的情况。请联系技术支持的同学反馈问题

2. 缺少fields指定字段返回

这种问题是指:用户调用接口返回成功,并且返回结果的结构也符合文档中的说明,但是在结构体中缺少了自己fields中指定的字段。如:用户调用接口,指定了fields为num_iid,title,price,sku,item_img,prop_img,但是返回的Item结构体中只包含了num_iid,title,price,sku,item_img字段,prop_img字段没有返回。

用户遇到这类型问题的时候,首先第一步要做的事情是查看文档,仔细根据版本确认自己传入的fields参数是不是正确的。因为top1.0和top2.0的某些字段命名是不一样的,如果传错了fields字段,那么这个字段就不会有返回。

如果用户确认自己的参数名称没有传错,但是就是么有结果返回,这个时候用户应该确认这个商品是否真的包含你所指定的参数。因为如果调用的结果就是不包含这个参数的,那么用户一定拿不到的。用户可以通过如下两种方法进行测试:其一,在页面上打开这个商品,如果页面显示也没有这部分信息的话,那么说明这个商品就是不包含这部分信息的;其二,更换指定的参数进行测试(如:获取另外一个确实有这个字段的商品看看有没有返回)。如果其他的参数能够获取到这个字段,说明是这个商品的数据问题,应作为正常流程处理掉。如果其他的确认有这个字段的参数仍然获取不到这个字段(也就是说无论传入什么参数都获取不到这个字段了),请联系技术支持的同学反馈问题,top的开发人员会去查看这些问题的。

七、 总结

Isv开发top应用总会遇到n多的问题。这些问题有些是用户调用错误造成的,有些是top平台服务错误造成的,有些是网络通信产生的。但总的看起来,绝大部分的错误调用都不是简单的请求重试可以解决的。因为top的逻辑比较复杂,用户传入的参数很多时候是会出现校验不通过的现象的,建议isv在每次调用出错的时候能把错误信息反馈给用户,让用户来决定是重试还是修正入参后再尝试,isv不应该在后台一直反复的重试。

当isv遇到调用错误时,首先应该尽量将自己的请求信息和响应信息保存下来,方便后面的问题分析。同时isv也应该定期的关注top的文档更新,里面对于淘宝的业务改动会做出一定的说明。当isv编写代码或调试问题的时候应该尽量仔细的查看top的文档,虽然写得不是很好,但是对于用户避免一些问题还是很有帮助的。

Top一直在不断改进中,欢迎大家将自己遇到的问题反馈给我们,让我们共同成长。

18

本文标签: 错误用户参数调用传入