大家在设计 RESTful API 时，出现错误时是返回 401、404、5XX 之类的，还是总是返回 200，是否成功在 body 里面用一个字段来指示？

[plantain]

基于怎样的考虑呢？

[kongkongyzt]

偏向于使用后者，比较方便

[yimity]

总是返回 200，但是我们的结构是 {code:X00,message:"XXX",data:{}}

[mcfog]

我个人喜欢全200

把500等错误码留给nginx等基础服务，因为我觉得http错误码就应该表示http的问题（bad gateway/internal server)，只要请求正常到达业务服务器，结果就应该是200，业务问题就应该用业务状态码表示

全200还有若干实际细节的好处，打比方阿里云看到你500 404什么的就会直接砍掉你的body，你的client到server之间有太多东西会经手你的http请求，大量使用200之外的状态码各种稀奇古怪的问题

另外我还是全post党，不如说我压根不觉得(严格的)RESTful有啥好的，先吹一阵然后在现实面前搞各种method override之类的妥协

[n37r06u3]

全200 。。。401除外。。。

[582033]

偏向前者

[jokester]

@mcfog 阿里云好棒

[virusdefender]

后者 全200 有个字段表示成功失败

[FrankFang128]

@mcfog 嗯，有些环境就是喜欢自作聪明，看见非 200 就瞎搞。比如一些手机客户端内嵌页面。

[FrankFang128]

@mcfog 你全用post怎么做缓存呢？

[gDD]

HTTPS FTW!

[pyKun]

@mcfog

> 不如说我压根不觉得(严格的)RESTful有啥好的
+1

> 打比方阿里云看到你500 404什么的就会直接砍掉你的body
500不清楚，404的body不处理好像是协议就这样的，我以前做别的server端的时候遇到过这个事

[caixiexin]

总是200，然后所有的返回结果里面都有result_code和result_desc的字段，可以统一接口的设计和开发。

这样开发的时候异常处理也可以集中在一个地方。
比如用java的spring mvc开发的接口，碰到异常情况（不管是业务异常还是系统异常）封装一个自定义的RuntimeException往外抛，然后在最外层的Controller增加统一HandleException的方法，根据不同异常封装不一样的result_code返回。这样不管是在业务层还是数据库层都只要关心自己的职责，不用去考虑异常处理。

[egen]

业务代码全使用200

有一点考虑是客户端只需要一处错误处理
使用 HTTP 错误，某个错误代码经常不够用，内部还要嵌入更细节的错误信息，这导致客户端需要做多次判断才能完整的处理错误，还不如直接做内部指定具体的错误信息

另外就是 @mcfog 所说的，HTTP 错误留给基础服务，对错误也是一个很好的分类

另外可以 GET 就 GET，不行该 POST 就 POST，API 设计不强求语义，怎么方便怎么来，最常见的就是 search 接口使用的就是 POST。

[hiddenman]

偏向前者。

[wzzyj8]

如果http必须全部200，很多地方的移动、联通、电信会劫持全部非200到自己的页面，如果你的body设置的有问题。。结果会非常惨烈。。有的时候你自己都会不知道用户那些莫名其妙的错误是怎么出现的

[mcfog]

@FrankFang128 嗯，POST不缓存在"纯获取"的接口方面是缺点（在有副作用的接口反而是优点吧，不用?_=RANDOM了），这个场景下是应该考虑用GET

[jjx]

后者, 错误就是错误