共计 1084 个字符，预计需要花费 3 分钟才能阅读完成。
1 对立接口格局
所有有对于接口返回的数据格式，都定义在 framework:cn/framework/common/http 包门路下。
1.1 MessageType
零碎中为了不便直观的应用，对所有 HTTP code 做了拦挡，除了网络谬误的申请，前端不再须要判断 404、500 等谬误，只须要依据 MessageType 判断是否胜利。
定义返回的音讯类型，间接确定下来前端依据这个音讯类型去打印不同的信息。
目前只定义了 WARNING、SUCCESS、ERROR 三种音讯类型，并且定义了相应的音讯内容，能够依据业务场景的减少扩大。
1.2 RequestResult
所有返回到前端的数据格式，都必须为此格局。
关键字段：
- MessageType type，信息类型，默认为胜利
- String message，音讯内容，如果为空应用 MessageType 中自带的音讯内容
- String reason，谬误音讯，用于在产生异样时，携带异样信息，不能用于展现给客户端
- Long code，口头码，用于与前端交互，扭转行为，没有可不设置，应用 type 代替就能够
- LocalDateTime time，变量生成工夫，用于帮助判断问题
- Object value，真正返回的业务数据，能够是任何可被序列化的数据
领有对立的数据格式，前端能力更好对立的解决信息。
1.3 InnerExp
外部异样，用于不便返回后果到前端。
对于外部异样，和其它异样的剖析，放在下一篇独自讲述。
2 http status code
http 的协定中，定义了很多状态码。
然而我认为在个别的前后端的业务交互上，咱们不须要这么多状态码，这些状态码，更多的是给还未达到后端的申请筹备的。
例如有些申请在 nginx 这一层就出现异常，此时 nginx 就能够依据一些状况返回对应的状态码，因为像 nginx 这种中间件，它要满足更加标准化的状况。
对此，框架中设计的音讯返回状态码，只有是达到了后端，一律返回 200，音讯只分为胜利、失败、正告三种。
如果有更加简单的场景，须要前端针对不同的异样类型，作为不同的反馈，例如登录失败的起因是明码谬误还是明码到期，下面的返回音讯体中，也能够自定义 code。
这样不仅简化了后端的解决形式，也大大方面了前端的解决难度。
前端获取的 response 只有是非 200 的，证实必定不是后端呈现了问题，将错误信息对立解决。
针对 200 音讯能够做对立的拦挡解决，针对谬误、正告音讯做出回应，胜利音讯放行。
咱们不须要对没有应用正统的 http code 这件事耿耿于怀，任何可能简化咱们开发的形式，都是一种好形式，以当下的事实环境来设计开发方式，如果将来不满足，再从新设计。