还能不能好好的写 API 了

我对 Rest 的理解是这只是个建议，往上面靠就行了，其实 status 返回 200 ，然后错误都用 error_code 表示，对客户端来说解析起来十分友好。 [做开放平台有感， rest 是一种思想

偶们都是 http status 返回 200 ，通过结果 ret 值表示业务 error

帖子里居然大部分都是全 200 的 ... 那这么看起来我是异类咯 ...

我的核心 API 是返 4xx / 5xx 的 ... 使用自签 SSL 双向认证 ... 所有后台和 APP 端都接这个 API ...

Web 端特殊一点 ... 前置了一个同域 Proxy 把所有返回再封一层变成全 200 ...

这么做有明确目的是为了防止每次都多一个跨域请求和 40x 状态码被拦截 ...

我不觉得为了妥协这两点就该改变整个 API 体系的设计思路 ...

换言之一个 HEAD 请求判断状态码能搞定的事情为什么还要用先 GET 再解析判断返回 ..?

@Sunyanzi 终于等到知己了！

😂

一般都返回 200,表示服务器正确响应。
返回结果 json 里面有 status 字段，表示这个 api 的返回状态。

@jianghu521 嘛 ... 知己归知己 ... 如果还不能像我一样独断专行说什么就是什么还是听领导的吧 ...

我的这个规范也是个人喜好 ... 便于阅读节省流量和逼格高什么的也就只能说给自己听听 ...

用户才不会管你用什么返回他们只要能用就行了 ... 之所以能推下去只是因为我的权力摆在这里 ...

所以说领导都是对的 ... 如果你觉得领导不对就再看一遍这句话 ...

前端的一般是 200 ，后端接口互通才是 REST ，毕竟前端有很多坑，加上开发很参差，要全程 rest 不容易。再者，有时候 http 的错误码是不够用的，或者说，不知道用那个表示更好。在搞了很多个前后端分离的项目后，最后全部都妥协成 200 了

@cxbig 深表同感

要么忍要么狠要么滚 你不能忍 狠过了也没用 那么。。。

其实开始我也有点纠结，因为 Http Status Code 是协议状态结果，而不是我应用（业务）流程结果，不一样啊，所以不能共用。
你说我请求一个 http ，它能正常返回呀，所以是 200 ，只是业务权限的限制，那也不能 403 呀，你说对吧。
后来想想确实也是这么回事，反正大家约定一个标准，约定一个行径就好了，没必要纠结

我也是全 200 了。。。我抗议过，无效 23333
其实我后来都快说服他了，但想想已经写好了，改来改去麻烦，就没改。
其实改起来也方便，我用的 django rest framework ，自己写了个错误处理，把状态码都设置成 200 了。。。

原来都是返回 4xx,5xx ，后来和别人对接争论太多，都说我 SB 。现在都不争了，直接返回 200 了
公说公有理，婆说婆有理。 RESTFUL 虽好，但要完整的遵守还是很困难。

我也给公司做了一个 Restful 的 API ，经常被做 APP 的问道你这个返回 204 是啥啊？成功不是 200 吗？能不能改成 200 啊？

搞啥 restful api 啊，搞搞普通 http api 得了

@Sunyanzi 这样的领导棒！👍🏿👍🏿

@zhs227 是的 人家觉得你很... 真是无语

@wizardoz 是的! 加油吧

@ty89 那个特性很早就被远程禁用了，你想开都不行

支持全部 200