1
kongkongyzt 2015-04-16 07:13:47 +08:00 via iPhone
偏向于使用后者,比较方便
|
2
yimity 2015-04-16 07:18:20 +08:00
总是返回 200,但是我们的结构是 {code:X00,message:"XXX",data:{}}
|
3
mcfog 2015-04-16 07:25:31 +08:00 via Android
我个人喜欢全200
把500等错误码留给nginx等基础服务,因为我觉得http错误码就应该表示http的问题(bad gateway/internal server),只要请求正常到达业务服务器,结果就应该是200,业务问题就应该用业务状态码表示 全200还有若干实际细节的好处,打比方阿里云看到你500 404什么的就会直接砍掉你的body,你的client到server之间有太多东西会经手你的http请求,大量使用200之外的状态码各种稀奇古怪的问题 另外我还是全post党,不如说我压根不觉得(严格的)RESTful有啥好的,先吹一阵然后在现实面前搞各种method override之类的妥协 |
4
n37r06u3 2015-04-16 07:43:23 +08:00
全200 。。。401除外。。。
|
5
582033 2015-04-16 08:42:35 +08:00
偏向前者
|
7
virusdefender 2015-04-16 08:56:18 +08:00 via Android
后者 全200 有个字段表示成功失败
|
8
FrankFang128 2015-04-16 09:01:27 +08:00
@mcfog 嗯,有些环境就是喜欢自作聪明,看见非 200 就瞎搞。比如一些手机客户端内嵌页面。
|
9
FrankFang128 2015-04-16 09:02:05 +08:00
@mcfog 你全用post怎么做缓存呢?
|
10
gDD 2015-04-16 09:05:25 +08:00 via iPhone
HTTPS FTW!
|
11
pyKun 2015-04-16 09:13:52 +08:00
@mcfog
> 不如说我压根不觉得(严格的)RESTful有啥好的 +1 > 打比方阿里云看到你500 404什么的就会直接砍掉你的body 500不清楚,404的body不处理好像是协议就这样的,我以前做别的server端的时候遇到过这个事 |
12
caixiexin 2015-04-16 09:28:06 +08:00
总是200,然后所有的返回结果里面都有result_code和result_desc的字段,可以统一接口的设计和开发。
这样开发的时候异常处理也可以集中在一个地方。 比如用java的spring mvc开发的接口,碰到异常情况(不管是业务异常还是系统异常)封装一个自定义的RuntimeException往外抛,然后在最外层的Controller增加统一HandleException的方法,根据不同异常封装不一样的result_code返回。这样不管是在业务层还是数据库层都只要关心自己的职责,不用去考虑异常处理。 |
13
egen 2015-04-16 09:28:39 +08:00
业务代码全使用200
有一点考虑是客户端只需要一处错误处理 使用 HTTP 错误,某个错误代码经常不够用,内部还要嵌入更细节的错误信息,这导致客户端需要做多次判断才能完整的处理错误,还不如直接做内部指定具体的错误信息 另外就是 @mcfog 所说的,HTTP 错误留给基础服务,对错误也是一个很好的分类 另外可以 GET 就 GET,不行该 POST 就 POST,API 设计不强求语义,怎么方便怎么来,最常见的就是 search 接口使用的就是 POST。 |
14
hiddenman 2015-04-16 10:00:24 +08:00
偏向前者。
|
15
wzzyj8 2015-04-16 10:04:41 +08:00 via iPhone
如果http必须全部200,很多地方的移动、联通、电信会劫持全部非200到自己的页面,如果你的body设置的有问题。。结果会非常惨烈。。有的时候你自己都会不知道用户那些莫名其妙的错误是怎么出现的
|
16
mcfog 2015-04-16 11:30:18 +08:00
@FrankFang128 嗯,POST不缓存在"纯获取"的接口方面是缺点(在有副作用的接口反而是优点吧,不用?_=RANDOM了),这个场景下是应该考虑用GET
|
17
jjx 2015-04-16 15:42:16 +08:00
后者, 错误就是错误
|