界面是系统和终端用户的交互接口，界面的美观与否，使用流程通畅与否，错误提示友好与否等等都直接影响到用户的体验，一个体验不好的系统相信
不会有用户青睐的。同理，系统之间进行交互，特别是不同的业务主体的业务系统之间进行交互，服务提供方和使用方就扮演了一个提供者和用户的角色。我看到经常有开发人员在处理外部接口时抓狂，骂别人接口写得烂，写得非常不好用，骂过了别人，那么自己写的接口呢?可能也被另一批人骂过了。那骂来骂去大家都在骂什么呢？其实这就说明了一个用户体验问题，服务提供方的用户在这里就是这群开发人员。
大家感觉不爽，绝大多数情况下不是说这个接口不能完成正常的功能，因为正常情况下，客户调用服务类接口，服务器接收请求并处理，一般都能够返回正确结果。然而事情并不总是这样美好，因为在服务调用过程中总会出现这样那样的问题，导致服务调用不成功，这时，如何准确向客户端提供错误反馈信息，帮助其准确定位调用出错原因是接口人性化的一个方面，否则处理不好则会让调用方抓狂，不明确的错误信息，不便于自动化处理的错误处理方式等等都会让用户很不爽，要知道我们有一半以上的代码都是在处理异常情况。
相信大家见过很多服务类接口的错误处理方式，比较牛B的是一律返回 "系统错误"，其他有用的信息统统没有。还有一类稍微好点，总算返回了字符串形式的 xxx错误，xxx不正确，请修改重新提交，但是仍然不利于自动化处理，并且错误返回信息千姿百态，不一而足。
我们都知道设计接口应该站在使用者的角度来考虑，那么站在用户角度是怎么考虑的呢？(当然，不同业务场景考虑会不一样)
不妨假设一下自己是接口使用者，对于某类订单状态更新接口，我可能会考虑：
1、希望接口在处理失败时能够返回具体的错误码，而不仅仅是错误描述，方便系统自动处理。
2、我要是接口签名是错误的或者无权限，提交请求希望能返回签名错误，或者说无权限，返回相应错误码
3、如果重复提交了请求，希望能告诉我请求提交重复，返回相应错误码
4、如果发送了错误的状态更新请求，告诉我不能更新状态，并反馈回当前的订单状态，返回相应错误码
5、如果发送了一个不存在的订单请求，告诉我该订单不存在，返回相应错误码
之所以考虑上诉东东，我可能是希望，第一：我的签名是错的，我的系统接收到这个代码后可能不会再发送请求，而是通知发消息通知管理员，或者自动更改签名，第二：重复提交请求是不可避免的，希望对方能告诉我，我不会再发请求 第三：如果是发送了错误订单更新请求，对方告诉我不能更新，而且告诉我当前的订单状态方便系统处理等等。一句话，接口设计关键是异常情况时，能够让接口调用方知道 失败了 如何自动补救或者处理。
下面我简单分类介绍一下一些需要考虑的地方(非教条，根据实际业务场景决定)：
服务类接口不外乎分为两类：
第一类：查询类接口，此类接口是向外提供基础 信息，不更改服务端状态
考虑的方面：1、无权限时(如果需要考虑权限的话)，返回无权限代码
2、无该类数据时，返回无该类数据代码
第二类：更新类接口，这类接口需要更改服务端数据状态，例如增加数据或者更改状态，这类接口一般是业务双方需要相互业务交流才会有。
考虑的方面 ：1、无权限时，返回无权限代码
2、重复调用时，告诉重复调用，或者告诉更新失败，并返回当前状态信息和错误代码
3、错误状态更新调用，告诉更新失败，并返回当前状态信息和错误代码
4、无该类数据时，返回无该类数据代码
