top错误诊断说明Word格式.docx
《top错误诊断说明Word格式.docx》由会员分享，可在线阅读，更多相关《top错误诊断说明Word格式.docx（15页珍藏版）》请在冰豆网上搜索。
这三种类型的错误分别代表了：
淘宝服务器、淘宝接入平台、top-api业务，几个层次上显现的问题。
1）
连接错误
连接错误是要求通信过程中显现的错误，这类型错误通常由响应码标记出来。
响应码由三位十进制数字组成，它们显现在由服务器发送的响应的第一行。
响应码分五种类型，由它们的第一位数字表示：
1xx：
信息，要求收到，连续处理
2xx：
成功，行为被成功地同意、明白得和采纳
3xx：
重定向，为了完成要求，必须进一步执行的动作
4xx：
客户端错误，要求包含语法错误或者要求无法实现
5xx：
服务器错误，服务器不能实现一种明显无效的要求
Isv调用top服务最常收到确实是200：
要求成功；
404：
未找到要求的服务；
500内部服务器错误等等。
假如用户收到的响应码是404，表示用户的网络有问题或者top被和谐了……假如用户收到的响应码是500，表示网络是ok的，是top的服务无法响应。
2）
服务端错误总述
平台解析错误和业务处理错误差不多上成功访问到top服务（响应码返回为200）之后所产生的错信息，他们top处理isv要求过程中显现的问题。
1.0和2.0的格式有所不同。
1.0的错误响应信息最外层为{“error_rsp”:
{}},表示这是调用错误所返回的信息。
里面一层包含两个元素：
”code”:
””和“msg”:
””，前者表示错误码是多少，后者表示错误信息是什么。
例如错误的调用1.0的taobao.item.get服务错误时返回的错误信息：
{"
error_rsp"
code"
40,"
msg"
"
Missingrequiredarguments:
missingparameteriid/num_iid"
}}。
那个信息的开头为error_rsp，表示这是调用错误所返回的结果。
里面包含的错误体的code为40，是平台型错误，表示错误是缺少了必传参数所引起的。
然后msg内容为Missingrequiredarguments:
missingparameteriid/num_iid，表示缺少的必传参数是iid或者num_iid。
Isv解析到这些信息后就需要依照错误信息改进自己传入的参数来使调用成功。
2.0的错误响应信息的最外层为{“error_response”:
””}，表示这是调用服务失败所返回的错误信息。
信息体里面一层总共包含了五个元素：
args"
arg"
[{“key”:
“”,”value”:
””},{“key”:
””}……]}，”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的taobao.item.get服务错误时返回的错误信息：
error_response"
[{"
key"
app_key"
"
value"
15739"
},{"
fields"
list_time,delist_time,approve_status"
format"
json"
method"
taobao.item.get"
nick"
tbtest561"
partner_id"
TOPTEST"
sign"
668FB4A049F71A1C845EF8C05B1F3E66"
timestamp"
2018-03-0518:
03:
06.325"
v"
2.0"
}]},"
530,"
Remoteserviceerror"
sub_code"
missing-parameter"
sub_msg"
iid和num_iid至少要传入一个"
}}
那个信息的开头为error_response，表示这是调用错误所返回的错误信息。
里面的args列出了用调用那个接口传入的信息有：
}]，这些信息是从用户的要求信息里面解析出来的。
错误码code为530，表示这是调用商品的api所产生的错误。
错误信息msg为Remoteserviceerror表示这是调用业务处理所产生的错误。
子错误码sub_code为：
missing-parameter，表示那个错误是因为缺少了参数所产生的。
子错误信息sub_msg为：
iid和num_iid至少要传入一个，表示少传的参数为iid或num_iid。
这所有的错误信息叠加起来能够明白，那个错误是用户调用taobao.item.get接口时业务处理发觉用户没有传入商品id所导致的。
3）
平台解析错误
平台解析错误是指top返回的错误码小于100的情形。
平台解析是非业务性的普适的校验接入层，要紧用于对用户的各种权限、和入参进行最差不多的校验。
现在的平台错误码要紧有：
Isv能够通过错误码和说明来纠正问题。
如：
错误码为3的响应表示图片上传失败，错误码为26表示用户没有传入session参数，错误码为27表示用户传入的session参数找不到对应的session记录，等等。
4）
业务处理错误
业务处理错误是用户通过平台校验进入业务流程显现了错误所发出来的。
这一层的错误码依照调用版本不同分为两种。
假如版本是1.0，那么返回的错误信息格式确实是：
{“error_rsp”:
{“code”:
XXX,”msg”:
”……”}}，里面的code是数字形式的标记着一种错误的编码，msg是字符串形式，标记在错误的具体信息。
如，猎取当商品失败的错误信息确实是：
551,"
Itemserviceunavailable:
猎取单个商品失败"
1.0的错误码有以下几种：
1.0的返回的错误code确实是其中的错误码，错误msg确实是其中的英文错误描述加上具体的错误信息组成的。
假如版本是2.0，那么服务器所返回的错误信息格式确实是：
{“error_response”:
””}……]},”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
增量API
600
比价
610
画报
620
江湖
630
分销
640
淘秀
650
收费
660
Misc（保证金等杂项api）
670
由上图可知，每一大类的api在2.0中事实上是共享一个code的，它能让用户在复杂组合调用中指导是哪一类的api显现了问题，实现初步的定位。
2.0的业务错误中，msg里面最容易显现的内容确实是Remoteserviceerror，这表示用户是在通过了平台校验后进行业务流程的时候显现的错误。
其他的错误还有RemoteServiceTimeout：
后台处理业务超时等等的错误。
这一个错误信息的力度比较粗，专门难单独用她进行错误处理。
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的程序中通常会表现为，响应解析格式错误。
例如：
用户使用的top的javaSDK客户端调用top服务，设置的format格式为json却得到了一个xml的响应，这是sdk就会报一个错误说响应开始处缺少一个“{”符号。
这是因为xml响应是以“<
”开始的缘故。
一样会发生这种现象的缘故有一下三种：
用户传入的参数过大导致流解析专门，用户调用太过频繁道士响应专门，top服务器故障。
为了定位到问题出在哪里，以便找到相应的解决方法，用户在遇到响应格式错误的情形时能够参考以下步骤进行调试。
响应格式格式错误，但数据正确
用户第一步应该分析一下相应的内容里面是不是除了格式错误以外，其他的响应内容差不多上正确调用的返回结果。
例如，有个用户用top的sdk，设置format为json，调用top得到了如此一个返回结果：
com.taobao.api.json.JSONException:
A
JSONObject
text
must
begin
with
'
{'
at
character
1
<
?
xml
version="
1.0"
encoding="
utf-8"
>
rsp>
totalResults>
1115<
/totalResults>
item>
iid>
!
[CDATA[77a003aef35f8d959eef03d7ba3d23e3]]>
/iid>
modified>
2018-03-01
16:
04:
15<
/modified>
/item>
[CDATA[c559afab73ab721a8e7500b62864add0]]>
05<
[CDATA[28a3410c88bc2ba2471080ce8891eaf7]]>
59<
[CDATA[915383f4733b7a7c2549aa863d305995]]>
53<
……
[CDATA[528223dc2d67213aa29ab84c74c6a60a]]>
07:
30:
52<
/rsp>
从那个专门的开头能够看到，这是sdk的json解析抛了一个专门，说响应内容的内容应该是以“{”开始的。
这说名，isv收到的响应格式确信出了问题。
再看一下响应的内容<
相应结果标签之间包含了totalResults和item列表，这些数据说明，这是调用商品查询接口返回的结果数据：
查询到的结果总数是1115条，当前页的商品iid和最近修改时刻也在其中。
这些查询结果数据是正常的，然而返回格式却不是传入的json而是变成了xml。
这位isv联系了top的技术支持，在建议减缓调用频率以后，返回的数据格式正常了，如此就临时操纵了这种情形的发生。
同时技术支持将这些情形反映到了开发，top这边后续就会找到问题根源，进一步杜绝这种情形的发生。
响应格式错误，数据也错误
假如用户第一步分析发觉，返回的信息并不是调用成功的信息而是某个平台错误，而且用户本身的参数并可不能导致那个错误的产生，现在用户就需要查看自己调用接口的参数了。
假如用户调用的接口需要传入比较大的数据（如：
图片、商品的长篇描述等等），那么用户应第一尝试着减小这些入参到合法范畴内输入（传入小图片或者之传入少量的描述文字等）。
假如用户调用成功，表示错误是因为用户入参太大造成了解析错误引起的，用户应配合自己所在地点的网速，要求大小等等的信息合理设置自己的参数大小和接口调用顺序。
假如用户减小参数依旧解析失败的话，用户尝试着不传入图片或只传入几个字节的描述的内容进行接口调用。
在传入描述只有专门少的字节的情形下：
假如不传图片调用成功了，那么应该是top的服务器的问题，请将那个情形反馈给技术支持进行解决；
假如图片不传调用仍旧失败了，那么应该是用户的调用参数或网络有问题，请认真对比文档说明对参数进行修改或等待网络状态好一点的时候进行调用。
总的来说，假如用户发生了响应格式错误的情形，一样分为三种情形：
用户本身传入的format确实是错误的，这种情形用户需要查看自己传入的参数是否正确；
用户通信的网络太差，服务端造成要求解析失败而丢失了format信息，这种情形下用户需要调整自己的网络通信情形，等状况复原再调用；
假如是其他由于图片或调用太频繁而引起的问题，用户需要减小图片或减缓调用来提高成功率，同时将这些情形通报给top技术支持的同学。
四、
平台级错误处理
在前文的错误综述中介绍过，top的错误能够分为平台级错误和业务级错误。
所谓平台级错误确实是指：
错误码小于100的调用错误。
这种错误一样是由于用户的要求不符合各种的差不多校验而引起的。
下面将关于各种平台级错误及相应的解决方法陈设于此。
错误说明
解决方法
3
图片上传失败
将传入的图片格式改为正确的格式、适当的大小的图片放进消息体里面传输过来。
假如传输仍旧失败需要减小图片大小或者增加网络带宽进行尝试
4
用户调用次数超限
调整程序逻辑合理利用api，等翌日再调用。
或者向技术运维的同学申请增加调用次数
5
会话调用次数超限
6
合作伙伴调用次数超限
7
应用调用次数超限
8
应用调用频率超限
Isv调剂api调用频率，不能太过频繁的调用
9
方法被禁止
请用大写的POST或GET，假如有图片等信息传入则一定要用POST才能够
10
服务不可用
多数是由未知专门引起的，用户认真检查自己传入的参数是否符合文档中描述的模样
11
开发者权限不足
appKey所对应的应用不具备权限调用当前接口。
需要联系运营或技术支持的同学开通调用该接口的权限。
12
用户权限不足
13
合作伙伴权限不足
15
远程服务出错
Api调用后端服务出错，isv第一查看自己的参数是否合法，假如参数没有问题请过一段时刻再尝试，假如还不行请联系技术支持
21
缺少方法名参数
传入的参数加入method字段
22
不存在的方法名
传入的method字段必需是你所调用的api的名称，同时该api是确实存在的
23
非法数据格式
传入的format必需为json或xml中的一种
24
缺少签名参数
传入的参数中必需包含sign字段
25
非法签名
签名必需依照正确的算法算出来的。
算法请见：
:
//open.taobao/dev/index.php/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-ddhh:
mm:
ss，例如：
2018-01-2520:
23:
30。
淘宝API服务端承诺客户端要求时刻误差为10分钟。
32
缺少版本参数
传入的参数中必需包含v字段
33
非法的版本参数
用户传入的版本号格式错误，必需为数字格式
34
不支持的版本号
用户传入的版本号没有被提供。
现在top只支持1.0或2.0两种版本
40
缺少必选参数
用户传入的参数中漏掉了必传的参数。
请认真对比文档检查
41
非法的参数
用户传入的参数不符合文档中说明的参数格式，请参照文档进行修改
42
要求被禁止
要求被禁止（目前没有在操纵）
43
参数解析发生错误或专门。
一样是用户传入参数非法引起的。
请认真检查入参格式、范畴、是否一一对应等等情形。
44
Isperror后台接入服务错误
这种后台服务专门引起的错误，请联系技术支持。
差不多上来说，平台错误是一个通用的、普适的校验。
一样针对用户的权限、安全、流量和最差不多的参数等等进行校验。
用户遇到这些错误的返回一定要第一步检查自己的权限、频率等情形；
然后就需要参照文档检验一下自己的传入的参数是否完整且合法；
假如这些都无法解决问题，请联系技术支持的同学进行反馈，top后台会尽快解决这些
升级会员 