1、一、 错误处理流程概览从这个错误处理流程可知，在整个错误处理的过程中，一共可以分为 3 条主要的流程：请求解析异常流程处理，平台级错误处理和业务调用错误处理。当然，这一切处理的最初也是最重要的一步就是：将服务器响应内容保留下来。二、 服务器响应内容透析服务器响应内容，顾名思义就是 isv 调用 top 服务得到的响应的内容。这些内容能够最真实的反应出 isv 请求的问题和服务器当前的情况，也最能够帮助isv 找到问题的所在。服务器响应内容一般分为两种：一种是 wiki 文档中所编写的成功调用所返回的字段，另一种是调用失败的返回的错误相关信息。1. 调用成功返回格式调用成功的响应信息内容根据调用
2、服务版本的不同分为了两种不同的格式。1.0 的服务返回信息的格式分为三层：最外一层是“rsp“: 标记，表示这是服务的响应内容；中间一层是返回结构体的标记，如：返回的是商品的结构体，中间这层就是“items“: , ，表示结果是一个商品的列表，如果返回参数不是以结构体的形式，这一层就不存在；最内一层就是每个结构体具体的字段了。1.0 这个版本所有返回结果，不论是单个的商品还是一个商品列表，他的第二层都是一个列表的结构，区别只是列表里有一个子结构体还是有多个子结构体而已。相比之下，2.0 的服务返回信息就相对的规范化了。2.0 的响应内容主要也可以分为 3 层：最外一层是你调用服务的名称所对应的
3、响应标记，如：获取单个商品（taobao.item.get）的响应最外层为“item_get_response“: ，表示这是获取单个商品的响应；中间一层是返回结构体的标记。如果结构体是单个，那么2.0 返回的这一层里面就会是单个的结构，如：获取的单个商品的结构体就是“item“: ；反之，如果结构体是多个，那么列表也会明显的表示出来，如：搜索商品列表的结构体就会是”items”:“item”: , 。最外层的 items 表示这是一个商品的列表，后面的 item 表示列表中的每一个子结构体都是属于商品item 的，然后就跟着商品的数据；最内一层就商品的具体字段信息了。2. 调用错误返回当调用
4、发生错误的时候，一般情况下可以分为几大类错误信息的返回：http连接错误、平台解析错误、业务处理错误。这三种类型的错误分别代表了：淘宝服务器、淘宝接入平台、top-api 业务，几个层次上出现的问题。1) http 连接错误http 连接错误是请求通信过程中出现的错误，这类型错误通常由 http 响应码标记出来。http 响应码由三位十进制数字组成，它们出现在由 HTTP 服务器发送的响应的第一行。响应码分五种类型，由它们的第一位数字表示：1xx：信息，请求收到，继续处理2xx：成功，行为被成功地接受、理解和采纳3xx：重定向，为了完成请求，必须进一步执行的动作4xx：客户端错误，请求包含语法
5、错误或者请求无法实现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 的错误响应信息
6、最外层为“error_rsp”: ,表示这是调用错误所返回的信息。里面一层包含两个元素：”code”:” ”和 “msg”:” ”，前者表示错误码是多少，后者表示错误信息是什么。例如错误的调用 1.0 的 taobao.item.get 服务错误时返回的错误信息：“error_rsp“:“code“:40,“msg“:“Missing required arguments:missing parameter iid/num_iid“。这个信息的开头为 error_rsp，表示这是调用错误所返回的结果。里面包含的错误体的 code 为 40，是平台型错误，表示错误是缺少了必传参数所引起的。然后
7、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”:”
8、”，”sub_code”:” ”和 ”sub_msg”:” ”。args 表示用户传入的参数列表是什么，里面是一个 arg 的列表会包含用户传入的所有参数信息，每个 arg 表示一个参数的信息，key 表示参数的名称，value 表示参数的内容，用以方便用户定位自己的错误；code 表示用户调用错误的错误码是多少，小于 200 表示平台级错误，200-1000 之间表示大范围的业务错误，即哪一类型的 api 调用发生了错误（根据 api 的大类来分，如：商品类的 api 是 530，交易类的 api 是 520，等）；msg 表示大类型的错误码所对应的错误信息，一般不具备独立的 debug 作
9、用，需要和 sub_code 和 sub_msg 一起使用才行；sub_code是调用错误的子错误码，他表示用户调用错误的原因；sub_msg 是子错误码所对应的错误信息，他用来补充细化子错误码的错误原因的。例如调用 2.0 的taobao.item.get 服务错误时返回的错误信息：“error_response“:“args“:“arg“:“key“:“app_key“,“value“:“15739“,“key“:“fields“,“value“:“list_time,delist_time,approve_status“,“key“:“format“,“value“:“json“,“ke
10、y“:“method“,“value“:“taobao.item.get“,“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-
11、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“:“taobao.item.get“,“key“:“nick“,“value“:“tb
12、test561“,“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 为：m
13、issing-parameter ，表示这个错误是因为缺少了参数所产生的。子错误信息 sub_msg 为：iid 和 num_iid 至少要传入一个，表示少传的参数为 iid或 num_iid。这所有的错误信息叠加起来可以知道，这个错误是用户调用taobao.item.get 接口时业务处理发现用户没有传入商品 id 所导致的。3) 平台解析错误平台解析错误是指 top 返回的 错误码小于 100 的情况。平台解析是非业务性的普适的校验接入层，主要用于对用户的各种权限、和入参进行最基本的校验。现在的平台错误码主要有：Isv 可以通过错误码和解释来纠正问题。如：错误码为 3 的响应表示图片上传失
14、败，错误码为 26 表示用户没有传入 session 参数，错误码为 27 表示用户传入的session 参数找不到对应的 session 记录，等等。4) 业务处理错误业务处理错误是用户通过平台校验进入业务流程出现了错误所发出来的。这一层的错误码根据调用版本不同分为两种。如果版本是 1.0，那么返回的错误信息格式就是：“error_rsp”:“code”:XXX,”msg”:” ”，里面的 code 是数字形式的标记着一种错误的编码，msg 是字符串形式，标记在错误的具体信息。如，获取当商品失败的错误信息就是：“error_rsp“:“code“:551,“msg“:“Item servic
15、e unavailable:获取单个商品失败“ 。1.0 的错误码有以下几种：1.0 的返回的错误 code 就是其中的错误码，错误 msg 就是其中的英文错误描述加上具体的错误信息组成的。如果版本是 2.0，那么服务器所返回的错误信息格式就是：“error_response”:“args“:“arg“:“key”:“ ”,”value”:” ”,“key”:“ ”,”value”:” ”,“key”:“ ”,”value”:” ”,”code”:” ”,“msg”:” ”,”sub_code”:” ”,”sub_msg”:” ”，里面的 code 是数字形式的标记着一种业务类型的错误编码，m
16、sg 则是比较大范围内的表示错误类型的字符串。而 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收费 660Misc(保证金等杂项 api) 670由上图可知，每一大类的 api 在 2.0 中其实是共享一个 code 的，它能让用户
17、在复杂组合调用中指导是哪一类的 api 出现了问题，实现初步的定位。2.0 的业务错误中，msg 里面最容易出现的内容就是 Remote service error，这表示用户是在通过了平台校验后进行业务流程的时候出现的错误。其他的错误还有 Remote Service Timeout：后台处理业务超时等等的错误。这一个错误信息的力度比较粗，很难单独用她进行错误处理。2.0 的业务处理错误信息主要要看 sub_code 和 sub_msg 这连个字段。sub_code 表示了服务费对业务错误的分类，sub_msg 表示了是错误原因。Sub_code 根据业务错误类型主要可以分为如下几类子错误码
18、 错误归类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-
19、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 由于数量超
20、过 40 个而产生了错误。错误响应时用户和服务器交互失败的最直接展示，isv 在调用 top 服务时，如果调用失败，请尽量保留下错误信息（建议尽量改用 2.0 调用，这个版本的错误信息比较全面），以便进行后面的错误追查。三、 响应格式错误处理响应格式错误是指用户调用 top 服务时，传入参数设置了 format 参数为json，但是接受到的却为 xml 的响应格式，或者设置格式为 xml 接收到的却为json 响应的格式的情况。一般正常情况下这种情况是不会出现的，但是还是会有一些异常的情况会引起这个问题。这种响应格式错误的问题在 isv 的程序中通常会表现为，响应解析格式错误。例如：用户使用的
21、 top 的 java SDK 客户端调用 top 服务，设置的 format 格式为 json 却得到了一个 xml 的响应，这是 sdk 就会报一个错误说响应开始处缺少一个“”符号。这是因为 xml 响应是以“11152010-03-01 16:04:152010-03-01 16:04:052010-03-01 16:03:592010-03-01 16:03:532010-03-01 07:30:52从这个异常的开头可以看到，这是 sdk 的 json 解析抛了一个异常，说响应内容的内容应该是以“” 开始的。这说名，isv 收到的响应格式肯定出了问题。再看一下响应的内容 相应结果标签之
22、间包含了 totalResults 和item 列表，这些数据表明，这是调用商品查询接口返回的结果数据：查询到的结果总数是 1115 条，当前页的商品 iid 和最近修改时间也在其中。这些查询结果数据是正常的，但是返回格式却不是传入的 json 而是变成了 xml。这位 isv 联系了 top 的技术支持，在建议减缓调用频率以后，返回的数据格式正常了，这样就临时控制了这种情况的发生。同时技术支持将这些情况反映到了开发，top这边后续就会找到问题根源，进一步杜绝这种情况的发生。2. 响应格式错误，数据也错误如果用户第一步分析发现，返回的信息并不是调用成功的信息而是某个平台错误，而且用户本身的参数
23、并不会导致这个错误的产生，此时用户就需要查看自己调用接口的参数了。如果用户调用的接口需要传入比较大的数据（如：图片、商品的长篇描述等等），那么用户应首先尝试着减小这些入参到合法范围内输入（传入小图片或者之传入少量的描述文字等）。如果用户调用成功，表示错误是因为用户入参太大造成了解析错误引起的，用户应配合自己所在地方的网速，请求大小等等的信息合理设置自己的参数大小和接口调用顺序。如果用户减小参数还是解析失败的话，用户尝试着不传入图片或只传入几个字节的描述的内容进行接口调用。在传入描述只有很少的字节的情况下：如果不传图片调用成功了，那么应该是 top 的服务器的问题，请将这个情况反馈给技术支持进行
24、解决；如果图片不传调用仍然失败了，那么应该是用户的调用参数或网络有问题，请仔细对照文档说明对参数进行修改或等待网络状态好一点的时候进行调用。总的来说，如果用户发生了响应格式错误的情况，一般分为三种情况：用户本身传入的 format 就是错误的，这种情况用户需要查看自己传入的参数是否正确；用户通信的网络太差，服务端造成请求解析失败而丢失了 format 信息，这种情况下用户需要调整自己的网络通信情况，等状况恢复再调用；如果是其他由于图片或调用太频繁而引起的问题，用户需要减小图片或减缓调用来提高成功率，并且将这些情况通报给 top 技术支持的同学。四、 平台级错误处理在前文的错误综述中介绍过，to
25、p 的错误可以分为平台级错误和业务级错误。所谓平台级错误就是指：错误码小于 100 的调用错误。这种错误一般是由于用户的请求不符合各种的基本校验而引起的。下面将对于各种平台级错误及相应的解决办法陈列于此。错误码 错误解释 解决办法3 图片上传失败 将传入的图片格式改为正确的格式、适当的大小的图片放进消息体里面传输过来。如果传输仍然失败需要减小图片大小或者增加网络带宽进行尝试4 用户调用次数超限5 会话调用次数超限6 合作伙伴调用次数超限7 应用调用次数超限调整程序逻辑合理利用 api，等第二天再调用。或者向技术运维的同学申请增加调用次数8 应用调用频率超限 Isv 调节 api 调用频率，不能
26、太过频繁的调用9 HTTP 方法被禁止 请用大写的 POST 或 GET，如果有图片等信息传入则一定要用 POST 才可以10 服务不可用 多数是由未知异常引起的，用户仔细检查自己传入的参数是否符合文档中描述的样子11 开发者权限不足12 用户权限不足13 合作伙伴权限不足appKey 所对应的应用不具备权限调用当前接口。需要联系运营或技术支持的同学开通调用该接口的权限。15 远程服务出错 Api 调用后端服务出错，isv 首先查看自己的参数是否合法，如果参数没有问题请过一段时间再尝试，如果还不行请联系技术支持21 缺少方法名参数 传入的参数加入 method 字段22 不存在的方法名 传入的
27、 method 字段必需是你所调用的 api的名称，并且该 api 是确实存在的23 非法数据格式 传入的 format 必需为 json 或 xml 中的一种24 缺少签名参数 传入的参数中必需包含 sign 字段25 非法签名 签名必需根据正确的算法算出来的。算法请见：http:/ 缺少 SessionKey 参数 传入的参数中必需包含 session 字段27 非法的 SessionKey 参数 传入的 session 必需是用户绑定 session 拿到的。如果报 session 不合法可能是用户没有绑定 session 或 session 过期造成的，用户需要重新绑定一下然后传入新的
28、 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 分钟。32 缺少版本参数 传入的
29、参数中必需包含 v 字段33 非法的版本参数 用户传入的版本号格式错误，必需为数字格式34 不支持的版本号 用户传入的版本号没有被提供。现在 top只支持 1.0 或 2.0 两种版本40 缺少必选参数 用户传入的参数中漏掉了必传的参数。请仔细对照文档检查41 非法的参数 用户传入的参数不符合文档中说明的参数格式，请参照文档进行修改42 请求被禁止 请求 被禁止（目前没有在控制）43 参数错误 参数解析发生错误或异常。一般是用户传入参数非法引起的。请仔细检查入参格式、范围、是否一一对应等等情况。44 Isp error 后台接入服务错误这种后台服务异常引起的错误，请联系技术支持。基本上来说，平
30、台错误是一个通用的、普适的校验。一般针对用户的权限、安全、流量和最基本的参数等等进行校验。用户遇到这些错误的返回一定要第一步检查自己的权限、频率等情况；然后就需要参照文档检验一下自己的传入的参数是否完整且合法；如果这些都无法解决问题，请联系技术支持的同学进行反馈，top 后台会尽快解决这些问题。五、 业务级错误处理业务级错误是指 isv 请求进入 top 业务处理以后爆出来的业务相关的错误，通常错误码分部在 500-1000 之间。Top 的业务错误一般可以分为 4 个大类：参数错误、权限控制、用户不存在和服务错误。1. 参数错误参数错误指 topapi 根据业务要求对用户传入的参数进行校验组
31、装的时候产生的错误。1.0 中的参数错误码有： 505,“Missing Parameters“;506,“Parameters error“;507,“Parameters Format error“和 XXX,”XXX not exist”(这里 XXX 表示未知的数字或字符串)等等。其中： 505 表示缺少传入某些需要传入的参数( 如：获取sku 列表的时候要求至少传入一个 iid，isv 却什么都没有传入 );506 表示传入的参数错误（如：传入的 iid 找到对应的商品已删除、传入的类目不存在等等）；507 表示用户传入的参数的格式不符合规定（如：需要传入数字的参数用户传入了非数字的
32、字符）；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 表示用户传入的参数错误（如：传
33、入的 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）中的说
34、明来进行入参修改。建议将这部分内容展示给用户，可以让用直观的看到错误的原因，从而改进输入。2. 权限控制权限控制的错误是指用户使用了自己不享有的服务所造成的错误。这类型的错误：1.0 的错误码为： 509,“Permission limited“；2.0 的子错误码为：invalid-permission。这类型的错误通常都是用户进行的操作触碰到了淘宝的业务规则，导致了 top 的业务校验不通过。如：用户没有登录却要获取某个卖家仓库中的商品，用户不享有多图服务却要上传商品多图或商品属性图片，成人类目直接上传图片，修改自动发货的商品，不是卖家或买家却要获取交易详细信息的这些错误并不是用户传入的参
35、数找不到相应的数据、或者传入的参数是错误的造成的。相反的，用户传入的参数都符合文档描述，但是用户不具备权限来进行相应的操作。在这种情况下，isv 有几条路可以选择。第一：对于查询类型的权限控制：如果用户是信息的所有者，那么需要让用户进行登录绑定，这样用户就够进行权限控制的操作了；如果用户不是信息的合法查看人，那么 isv 要明确的告诉用户这个操作不可以进行，并且不要进行重试操作了。第二：对于增删改类型的操作的权限控制：如果用户是因为没有享有服务（如：没有享有图片空间的服务）而产生的权限限制，isv 需要引导用户去进行服务的开通后再来进行操作，之后再重新调用接口；如果是因为用户操作了别人的数据而
36、引起的权限控制，那么 isv 要明确的跟用户报错，并且不能再进行重试操作。总之，当用户遇到报权限控制的错误时，isv 不能直接进行重试。应该将问题直接告诉用户，并引导用户进行相关的登录、开通服务等操作来调整权限以后，再让用户重试操作。如果用户不愿意进行调整，isv 此时应该直接停止该操作，不能默认的进行重试，因为这种前提下，重试是完全没有作用的。3. 用户不存在用户不存在是指 top 后台根据用户绑定的 nick 或者传入的 nick 对用户信息进行查询的时候找不到用户记录所报出的错误。1.0 的错误码：601, “User not exist“；2.0 的子错误码：user-not-exis
37、t。用户遇到这种问题首先请确认调用的这个接口自己有没有传入 nick 这个参数。如果 nick 是根据用户绑定的 session 取得的，那么用户需要过一会儿再重新调用看看。如果隔一段时间还不行，请联系技术支持解决。如果用户自己通过参数传入了 nick，那么请用户仔细检查自己传入的 nick是否正确。例如：有没有多一个空格或者大小写错误的？该用户是否确实存在的？等等。如果问题是因为名称错误或用户确实不存在引起，用户需要更改输入参数后才能再次调用。如果用户名称正确，用户也确实存在，却还是报用户不存在错误，用户需要检查传入的 nick 是否包含难以识别的编码的字体。如果 nick 中包含了火星文或
38、者其他编码的字体，请考虑将 nick 转换成 utf8 以后重新尝试或者放弃此次操作。如果上述问题都不存在，请联系技术支持的同学进行查看。整个查错过程如下所示：4. 服务错误服务错误主要指用户的请求通过了 api 业务的基本校验，在调用后台服务的时候由于出现了异常或者更进步的业务报错而产生的错误。这一类错误主要分为 3 个大类：服务调用错误、服务调用异常、远程调用错误、top 解析错误。a) 服务调用错误服务调用错误，是指通过 top 校验进入后端调用服务以后，由于不符合进一步的业务逻辑校验而出现的错误。如：发布商品的属性不符合商品类目的要求，评价的交易已经过期等等。这些错误在 1.0 的错误
39、返回错误码为：XXX,”XXX service error”，在 2.0 的返回子错误码为：XXX-service-error。用户遇到这种返回表明 top 的服务是正常的，是用户的参数不合规定所引起。请根据返回的具体 msg 和 sub_msg 内容定位问题，然后改正入参后再调用。如果确认参数错误却一直通不过调用，请联系技术支持的同学咨询情况，切勿盲目重试。b) 服务调用异常服务调用异常是指服务调用过程中由于后端服务器没有响应或者产生了异常或者 top 服务本身产生了未被捕获的异常而产生的错误。这些错误在 1.0 的错误返回错误码为：XXX,”XXX service unavailable”
40、，在 2.0 的返回子错误码为：XXX-service-unavailable。这种错误有可能是后端服务暂时不可用所引起的，所以用户遇到这种错误时首先应该查看返回的错误信息里面有没有有效的提示信息，如果有请先按照提示改正问题再调用；如果没有有效的提示信息，请等待一段时间再调用。如果一直都是这个错误，请联系技术支持查看问题所在。切忌立即反复重试。c) 远程调用错误远程调用错误是指 top 在调用后方服务时发生了调用错误或超时的情况。这类错误可能是由于后端服务过于繁忙或者服务失效引起的。这些错误在 1.0的错误返回错误码为：900,“Remote Connection Error“，901,“Re
41、mote Service Timeout“，902,“Remote Service Error“，在 2.0 的返回子错误码为：remote-service-error， remote-service-timeout，remote-connection-error。用户遇到这种情况，首先考虑的是等待一段时间重试看服务是否恢复。如果服务已经恢复，则这个只是短时间服务过于拥挤造成的；如果多次重试仍然是不可用，那么这个可能是后端服务出了问题，请联系技术支持进行处理。d) Top 解析错误Top 解析错误目前主要针对的是用户调用 top 服务时产生的未被捕获的空指针或者参数转换异常所产生的错误。这些错
42、误是由于用户的请求有错误引发了top 本身的服务流程的潜在隐患所引起的。 1.0 的错误返回错误码为：510,“Top parse error“，在 2.0 的返回子错误码为：top-parse-error。用户遇到这种问题时，请先仔细检查自己的参数，根据文档说明修改完善以后再尝试调用，一般正常情况，只要入参合法是能够成功的。如果确定参数正确的前提下还是调用报这个错误，请联系技术支持的同学反馈这个问题。六、 返回参数缺失处理返回参数缺失是指用户调用 api 返回成功，但是消息体里面的内容和所请求的内容不一致的情况。这种情况细分可以分为三种情况：整个消息体为空、消息体缺少文档定义的结构返回、返回
43、的结构体中缺少 fields 指定的某些字段的返回。1. 整个消息体为空或缺少文档中说明的结构体返回。整个消息体为空或缺少文档中说明的结构体是指：返回结果是非失败的情况下，得到的 Response 的 body 内容和文档定义不一致（比文档写到要缺少某些内容）的情况。例如：调用新增商品接口，正常的返回结果 1.0 是：“rsp“:“items“:“created“:“2009-11-17 16:30:50“,“iid“:“cbf8d5d64b3fc80b25d21b1e1c88fd41“。2.0 的返回结果是：“item_add_response“:“item“:“iid“:“699e0a75
44、fcea3966d1d57fc8278c674b“,“created“:“2009-10-22 15:08:42“。根据文档的说明：添加商品成功的返回结构体中包含的数据就是这样。以此种返回结果举例，整个消息体为空的情况是指返回的结果为： 或“item_add_response“: 。这个消息体里面什么东西都没有，既没有报错的信息，也没有成功响应的数据在里面。如果遇到此种情况，并且这个情况是在某种条件下课重复出现的，这表示 top 后端服务的流程出现了异常流程，请尽快联系top 的技术支持反馈问题。缺少文档中说明的结构体，以上述添加商品的 2.0 服务的例子来说，返回回来的结构可能就是：“ite
45、m_add_response“:“item“:“iid“:“699e0a75fcea3966d1d57fc8278c674b“、“item_add_response“:“item“:“created“:“2009-10-22 15:08:42“、“item_add_response“:“item“: 等等情况。如果用户遭遇了这个情况，并且这种情况是可重复出现的，并且切换参数也还是这样，这说明 top 的调用成功了，但是服务器返回的数据出现了不正常的情况。请联系技术支持的同学反馈问题2. 缺少 fields 指定字段返回这种问题是指：用户调用接口返回成功，并且返回结果的结构也符合文档中的说明，但
46、是在结构体中缺少了自己 fields 中指定的字段。如：用户调用taobao.item.get 接口，指定了 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 字段，那么这个字段就不会有返回。如果用户
47、确认自己的参数名称没有传错，但是就是么有结果返回，这个时候用户应该确认这个商品是否真的包含你所指定的参数。因为如果调用的结果就是不包含这个参数的，那么用户一定拿不到的。用户可以通过如下两种方法进行测试：其一，在页面上打开这个商品，如果页面显示也没有这部分信息的话，那么说明这个商品就是不包含这部分信息的；其二，更换指定的参数进行测试（如：获取另外一个确实有这个字段的商品看看有没有返回）。如果其他的参数能够获取到这个字段，说明是这个商品的数据问题，应作为正常流程处理掉。如果其他的确认有这个字段的参数仍然获取不到这个字段（也就是说无论传入什么参数都获取不到这个字段了），请联系技术支持的同学反馈问题，
48、top 的开发人员会去查看这些问题的。七、 总结Isv 开发 top 应用总会遇到 n 多的问题。这些问题有些是用户调用错误造成的，有些是 top 平台服务错误造成的，有些是网络通信产生的。但总的看起来，绝大部分的错误调用都不是简单的请求重试可以解决的。因为 top 的逻辑比较复杂，用户传入的参数很多时候是会出现校验不通过的现象的，建议 isv 在每次调用出错的时候能把错误信息反馈给用户，让用户来决定是重试还是修正入参后再尝试，isv 不应该在后台一直反复的重试。当 isv 遇到调用错误时，首先应该尽量将自己的请求信息和响应信息保存下来，方便后面的问题分析。同时 isv 也应该定期的关注 top 的文档更新，里面对于淘宝的业务改动会做出一定的说明。当 isv 编写代码或调试问题的时候应该尽量仔细的查看 top 的文档，虽然写得不是很好，但是对于用户避免一些问题还是很有帮助的。Top 一直在不断改进中，欢迎大家将自己遇到的问题反馈给我们，让我们共同成长。
