这是一个创建于 2897 天前的主题，其中的信息可能已经有所发展或是发生改变。
刚去一个公司，喷了一个没写过接口的后台开发人员，结果搞的自己也很 Lower 。喷的原因很简单，接口地址写错，参数写错，拖延整个项目进度，压缩自己的开发时间，随意更改字段名。 现在决心不说话，避免被说成是心态不好，大惊小怪。好无语。求安慰。
重要的不是能力，而是和谐的团队氛围，你认同这句话吗？
第 1 条附言 · 2017-01-23 16:20:16 +08:00
统一回复各位：第一次玩 V2Ex,没想到这么多人浏览和回复。感谢大家！
总结下：
1.的确是我这个心态不好,即使有什么问题，即使因为对方的问题拖延了整个项目,压缩了自己的项目开发时间,甚至导致整体的延期与加班,也应该委婉的去表达自己的意思。另外项目是公司的,拖延了自然会有上面的人去找原因,我刚去又只是个小兵,更何况在试用期(虽然我不在意找工作这件事)，但如果控制不了自己的脾气是成不了事情的。
---无论你工作多久,去一家新公司,你就是个新人,毋庸置疑。少说话多做事。
2.我只是喷(而非骂,指出具体错误的地方和建议,当然可能语气会有不好的地方。),但是稍微大点的公司都会有些办公室政治(大家都懂的)，对方即使有什么问题，最好能够私下沟通，不要放到明面上。把别人变 lower 的同时自己也会很 lower 。何必给自己和他人添堵呢?
--- 闷声发大财,做好自己的工作,但工作不是全部,要想自己生活的开心,最重要也最基本的,不给自己添堵。
3.进入社会 7 年有余,因为自己的火爆脾气吃了不少亏,但是行走江湖,脾气不好,又想吃好或者没有其他手艺只能吃这碗饭,要么是仗剑倚势不怕得罪人，要么就改掉自己的脾气做个老实人。千万不要落个无才无德最无用的结局，所以摆正好自己的心态,把工作做好,默默的提升自己.把日子踏踏实实的过好了而且越来越好才是最最重要的。
--- 连自己都控制不了的人,怎么去领导别人? 怎么让自己一步步的走向成功呢？
4.无意间见到几个现实中熟识的朋友在这里,就不在这继续发着无用的牢骚，撒播负能量了。
最后：写了很多废话,请各位见谅.感谢一路走来遇见的人。无论是好人还是坏人,技术好的还是技术差的,男的还是女的.感谢让自己成长的人,祝愿各位 2017 新年快乐！
总结下：
1.的确是我这个心态不好,即使有什么问题，即使因为对方的问题拖延了整个项目,压缩了自己的项目开发时间,甚至导致整体的延期与加班,也应该委婉的去表达自己的意思。另外项目是公司的,拖延了自然会有上面的人去找原因,我刚去又只是个小兵,更何况在试用期(虽然我不在意找工作这件事)，但如果控制不了自己的脾气是成不了事情的。
---无论你工作多久,去一家新公司,你就是个新人,毋庸置疑。少说话多做事。
2.我只是喷(而非骂,指出具体错误的地方和建议,当然可能语气会有不好的地方。),但是稍微大点的公司都会有些办公室政治(大家都懂的)，对方即使有什么问题，最好能够私下沟通，不要放到明面上。把别人变 lower 的同时自己也会很 lower 。何必给自己和他人添堵呢?
--- 闷声发大财,做好自己的工作,但工作不是全部,要想自己生活的开心,最重要也最基本的,不给自己添堵。
3.进入社会 7 年有余,因为自己的火爆脾气吃了不少亏,但是行走江湖,脾气不好,又想吃好或者没有其他手艺只能吃这碗饭,要么是仗剑倚势不怕得罪人，要么就改掉自己的脾气做个老实人。千万不要落个无才无德最无用的结局，所以摆正好自己的心态,把工作做好,默默的提升自己.把日子踏踏实实的过好了而且越来越好才是最最重要的。
--- 连自己都控制不了的人,怎么去领导别人? 怎么让自己一步步的走向成功呢？
4.无意间见到几个现实中熟识的朋友在这里,就不在这继续发着无用的牢骚，撒播负能量了。
最后：写了很多废话,请各位见谅.感谢一路走来遇见的人。无论是好人还是坏人,技术好的还是技术差的,男的还是女的.感谢让自己成长的人,祝愿各位 2017 新年快乐！
 |
1
RE 2017-01-22 21:40:18 +08:00 via iPhone
有问题不能好好说，一定要喷？以为跟混论坛一样呢
|
 |
2
nicevar 2017-01-22 21:44:31 +08:00
同事一上来就喷？平时网上喷习惯了吧，先沟通一下再喷也不迟
|
 |
3
hiboshi 2017-01-22 22:04:37 +08:00
能控制住自己情绪的人能成大事。
|
 |
4
HLT 2017-01-22 22:07:53 +08:00
刚去就喷人，之后有你受的。。。
|
 |
5
hexzhou 2017-01-22 22:08:32 +08:00 via iPhone
楼主你有点专家心态了，你也知道别人没写过，一上来就开喷。
|
 |
6
jmc891205 2017-01-22 22:22:22 +08:00
你可以邮件写明情况指出他的错误并抄送通知他 manager
直接骂人就显得不太会混职场了 |
 |
7
liangWL 2017-01-22 22:31:00 +08:00
楼主。我认同你说的最后一句话，但是，喷人就不好了，你可以向上面反映，直接扣工资，就 ok,他会记住你的，而且肯定会改正的，短时间之内会恨你，等他想明白了，就会感激你的，其实默默做个好人也行，我不介意别人认为我有多坏，自己问心无愧就好。
|
 |
8
lalalanet 2017-01-22 23:08:12 +08:00
重要的是你换个靠谱的公司，打工找个同事平均水平比自己高的公司上班去
|
 |
9
imlewc 2017-01-22 23:13:14 +08:00
改东西？
有原因么？ 好的原因要接受 不要一开始就喷 这样对自己身体不好 要是傻逼顺便改的 .... 立下规矩 |
 |
10
lcdtyph 2017-01-22 23:18:51 +08:00  1
楼主说的“喷”显然不是骂了那个人的意思吧……
|
 |
11
Immortal 2017-01-23 00:05:41 +08:00
就是流程太乱。。。
我写服务端 也就写了 1 年 api 之前一直在做 web 两边都有问题吧 |
 |
12
ihuotui 2017-01-23 00:13:33 +08:00
改变能改变，不能改变就接受或者换一个地方。
|
 |
13
noli 2017-01-23 00:26:38 +08:00 1
这有什么，我今天喷了一个 Android 兼职过来写 php 后台不懂什么叫 Http Status Code 的家伙。
能用 400 Bad Request 解决问题非要返回一个字符串或者 json 的。 反正又不是我发工资，我喷他为毛呢。 当然，我的重点其实是想说 php 是最好的语言。 |
 |
14
ETiV 2017-01-23 00:37:33 +08:00 via iPhone
长者教导我们闷声发大财，所以我从来都是看在眼里，记在心上。
|
 |
15
yxzblue 2017-01-23 01:02:06 +08:00 1
这也来求安慰！心真大
|
 |
16
srx1982 2017-01-23 01:06:42 +08:00
地址，参数，字段名，如果有接口文档的话不会写错吧？如果文档详尽易懂再写错就是诚信了吧？前提是详尽易懂哦
|
 |
17
yangqi 2017-01-23 01:23:43 +08:00
就是心态问题，不说话更是心态问题。谁不是从没有经验过来的？有什么问题好好说不行？
|
|
18
yangqi 2017-01-23 01:24:43 +08:00
另外，能力很重要，但是团队的和谐比能力更加的重要
|
 |
19
Phariel 2017-01-23 02:14:46 +08:00 via Android
楼主啊你要记住 喷人者恒被喷之 你是典型的一时爽
|
 |
20
janstk 2017-01-23 07:25:44 +08:00 via Android 1
哟哟。楼主我认得你。 m 神啊😂😂
|
 |
21
des 2017-01-23 08:47:25 +08:00 via Android 1
@noli 如果是业务逻辑出错，用 JSON 不是挺好的吗？不过用字符串就纯属坑人了。
等会。。。 400 Bad Request ，你确定不是你自己的锅吗？？ |
 |
27
yidinghe 2017-01-23 09:07:13 +08:00 via Android 1
纯粹的喷，对方是听不进去的，你最终也只是发泄而已。当我要表达不满的时候，首先会考虑对方是否已经和我一样意识到问题存在，如果是，那我就跳过喷的阶段，直接给些有用的意见。
|
 |
31
yoke123 2017-01-23 09:13:19 +08:00
大兄弟 都是打工的 何必呢 都退一步 你好我好大家好+_+
|
 |
32
TonyYOYO 2017-01-23 09:30:46 +08:00 via iPhone
最可怕我给服务端指出问题，人家就是不改…一个借楼搞定的事儿，非得俩
|
 |
35
mengzhuo 2017-01-23 09:44:40 +08:00
╮(╯▽╰)╭
RESTFUL 用 status code 是标准啊，但不上 https 没有意义，客户端能力跟不上也没有意义。 所以最后一般都会妥协成返回 json ，内含错误码。 |
 |
40
jtam 2017-01-23 09:56:07 +08:00
很 Lower ……
|
 |
42
mazyi 2017-01-23 10:36:42 +08:00
接口定义好了就不准备，变了就骂，
|
 |
43
pengfei 2017-01-23 10:44:59 +08:00
有接口设计文档呀
|
 |
44
shenhongbang 2017-01-23 10:46:39 +08:00
想解决问题呢就好好说话好好沟通，想单纯的干架就是一上来就喷喽
|
|
46
noli 2017-01-23 11:05:51 +08:00
|
 |
47
holy_sin 2017-01-23 11:24:55 +08:00
你咋没削他呢
|
 |
48
yura93 2017-01-23 11:34:40 +08:00
接口地址和参数和 Json 例子不是应该测试完毕 API 后放到内部开发平台上给前面人用吗?也不是需求变,自己频繁更改,可能没经验
|
 |
49
kanezeng 2017-01-23 11:59:17 +08:00
@noli 大家说得没错啊， RESTFul 不是协议，也不是规范，只不过是诸多 WEB API 设计架构中被比较多人说得比较多的一种而已。
没人规定说 WEB API 一定要按 REST 来设计，事实上能看到的很多 API 要么并不按 REST 来做，要么并没有严格按照 REST 来做。 总结一下，上面说的那么些，我想表达的是 REST 只不过是一种架构，做 WEB API 时不需要一定要跟着他，同样大家在这里讨论 WEB API 的时候，也不需要拿他来说什么。 那么说回用 HTTP 状态码，还是单独返回一个状态码？这个我估计 V2 上可能都争论过很多次，支持的双方都有吧。 从我个人来说，我更喜欢单独返回一个状态码，用来把业务逻辑的状态，和非业务逻辑的状态区分开来。 再总结一下，后面说得这么些，我想表达的这两种做法没有绝对的对错，没有必要因为别人和自己的选择不同而喷对方。这个选择应该是公司来做，如果公司没做好，喷的是公司。 |
 |
51
mikulch 2017-01-23 12:11:34 +08:00 1
感觉国内的人工作的怨气很大，性格很焦躁啊。
是不是觉得你喷了别人了所以显得自己特别牛逼？ 当工作合作上出现问题的时候，自己是否想过，做过下面这些？ 1. 对方这样写的理由是什么，是否因为某些需求不好解决或者临时性的需求变更，所以才这么做的？ 2. 和对方沟通，告诉他你的临时解决方案，对我造成了很大的困扰。所以我们应该一起拿出一个更好的解决方案。 3. 不要觉得大家都是傻逼，自己是聪明人。职场上做的好人往往是你们看不起的傻子，而不是经常显摆自己很聪明的那种人。 4. 谦虚是一种很可贵的品德。项目是团队做出来的，不是一个人搞出来的。 |
 |
52
break 2017-01-23 12:26:52 +08:00 via iPhone
别人没写过，有啥好喷的，你行你上啊。带带人家呗
|
 |
53
assassinpig 2017-01-23 13:43:38 +08:00
有的就是重视说出来, 之后就没事了，谁能不错，错了还不能说才是问题
有的就是不能直接说粗来，怕伤了和气, 彼此以后不好再见面 |
 |
54
baoguok 2017-01-23 13:54:09 +08:00
项目去求、接口定义，这些前期确定了，后面就按照文档开发，怎么会有频繁更改的问题。
很显然是公司没有流程，和写没写过接口无关 |
 |
55
mhycy 2017-01-23 14:45:09 +08:00
@noli 不止应用层会抛 HTTP 状态码，依据不同的环境架构，有时候直接 200 使用 json 格式返回状态码会是更优的做法。
|
 |
56
learnshare 2017-01-23 14:51:10 +08:00
老司机带带他，何必歧视小学生
|
 |
57
just4test 2017-01-23 15:07:04 +08:00
|
 |
58
zhoubug 2017-01-23 15:18:23 +08:00
做些无啥含量的 REST 交互 无论前后台有啥资格互喷的。。。
|
 |
59
jucelin 2017-01-23 15:41:23 +08:00 1
@just4test https://www.v2ex.com/t/191534 这个应该是他（@mhycy ）说的一种情况
|
|
61
ihuotui 2017-01-23 15:54:03 +08:00
如果用 HTTP 状态码 ，就是把 协议变为两个，一个 HTTP 状态码 一个 json ，复杂度增加。
然后用 HTTP 状态码 越具体，越不能拓展，就像泛型一下才好拓展，越抽象越好拓展。 |
 |
62
tairan2006 2017-01-23 16:24:39 +08:00
换公司，下一题
|
 |
63
sobigfish 2017-01-23 16:42:33 +08:00
接口地址写错，参数写错，拖延整个项目进度，压缩自己的开发时间，随意更改字段名....
话说 API 没文档？这个锅应该 pm 背吧 |
 |
64
simo 2017-01-23 18:04:30 +08:00
唉，和和气气，坐办公室油子，谁都会， but ，真不容易做到。
|
|
65
simo 2017-01-23 18:10:10 +08:00
|
|
66
noli 2017-01-23 18:50:05 +08:00 via iPhone
@mhycy 但是 4XX 错误肯定不是环境的问题啊，更进一步，如果不是协议上的问题而是例如连接问题，你扔个 200 过去也不能保证客户端能正确接收
|
 |
67
jarlyyn 2017-01-23 19:04:31 +08:00
慢着，楼上那些讨论 api 的。
为什么 4xx 错误会和 json 的状态码有关系？ 4xx 错误不是对应的是 200 么？ 就算 4xx 错误，典型如 422,也要返回具体的错误数据啊？ 跑 2xx,3xx,4xx,5xx 只是为了让缓存服务器和客户端更好的处理啊。 |
|
68
mhycy 2017-01-23 19:21:27 +08:00
@noli 要考虑到网络上各种奇葩的中间设备会有的奇葩规则，开发时还是要看 API 用在哪个地方
如果是内网，不经过啥奇葩的中间设备的话， HTTP 状态码直接表示资源状态也是可以的。 但是在外网，考虑到各种奇葩的中间设备有可能存在的情况下， 200 是个更稳妥的选择。 |
 |
69
dantangfan 2017-01-23 19:29:49 +08:00
一个吐槽贴，被强行转成了状态吗的月经贴。
|
|
70
noli 2017-01-23 19:36:25 +08:00 via iPhone
@mhycy 考虑的设备更多应用涉及的规模越大才更应该好好地使用 Http 状态码，毕竟 http 状态码是 RFC 上定义的而你自己定义的状态码只是你的什么鬼文档里定义的。 试图在一个庞大系统中的单点解决所有问题，这是想得太多，优化太早。
|
 |
71
hcymk2 2017-01-23 19:39:03 +08:00
|
|
72
hcymk2 2017-01-23 19:41:00 +08:00
|
|
73
mhycy 2017-01-23 20:25:56 +08:00
|
|
74
noli 2017-01-23 21:55:36 +08:00
@mhycy 你说的原则我很同意。但我觉得 Http Status 比 Json 或者别的什么格式表示的 status 更“通用”，更简单更暴力更少歧义。任何一个合格 Http Client 都肯定能解析得出这个 http status 。
|
|
75
mhycy 2017-01-23 22:00:12 +08:00
@noli
当你遇上一个没法更改的机房设备的时候你就不会这么说了。。 HTTP 状态码来表示资源状态那当然是很好的做法 但是当网络路径中存在一些奇葩的设备带有奇葩规则的时候这就不是一个合适的选择了 这也是我在上文中强调“外网”的原因。 |
 |
76
jingniao 2017-01-23 22:22:09 +08:00
手上的项目其实挺想用成 rest ful 标准的的状态码的。
但没用，前端没配合，可能在他们眼里，这是给他们增加工作量 |
|
77
noli 2017-01-23 22:22:25 +08:00
@mhycy 你说的不就是 明文 HTTP 被中间设备篡改内容 而已嘛。担心这个，上 HTTPS 才是正途，而不是在 API 上面搞什么自主创新，开发者的时间重新发明轮子来处理这个问题根本就是浪费时间。
|
|
79
noli 2017-01-23 23:10:36 +08:00
@mhycy 我知道在使用劣质 CA 签发的证书的情况下 HTTPS 可以等于没有，但排除这种情况之后， HTTPS 是无法劫持的。即使是存在劣质 CA 这样情况，因为存在 HTTPS 劫持的缘故多花时间重新做一套本来解决 HTTP Status code 就足以解决的问题，依然是不值得的。并且，如果连 HTTPS 劫持都做得出来，你觉得我们讨论在 JSON 里面放 400 还是用 HTTP Status 来放 400 什么的，这些还有意义吗？
|
|
80
mhycy 2017-01-23 23:30:27 +08:00
@noli
其实我想说的情况是公司内部自签发证书在网关拦截请求进行监控的情况下 HTTPS 是不可靠的。 考虑到运维以及可能出现的各种网络问题引起的状态码异常（客户端劫持） 我是认为 Web 环境中不适宜用 HTTP 状态码来代表业务状态，软件的 API 倒是可以用这种形式来实现。 但是为了明确区分应用层故障还是网络异常， HTTP 状态码保持 200 在某些时候是更合适的选择。 |
|
81
noli 2017-01-24 01:17:23 +08:00
@mhycy 你说的情况通常都是针对浏览器、 web 内容为主的应用，这种情况会需要担心网关和证书。 但对于 Restful API Client 来说，你可以指定要信任的少数证书，那么 HTTPS 是不可能被劫持的。在这种前提下，我们才可以无后顾之忧地讨论 API 设计。从这个基础开始出发，我来举例为什么总是保持 200 是不好的： HTTP 协议本身就已经工作在应用层，就是一个应用层协议，但是 HTTP 本身也有会话（ Session ）的概念，总是保持 200 会强迫不同协议层面（例如会话层）必须深入理解应用层协议才能决定如何处理会话。比如， HTTP 4XX 5XX 这种是一种很常见的足以让中间节点判断是否可以中断会话的信号，以及请求幂等性和结果缓存等等等优化。通通都用 200 来表示，莫非是打算叫 CDN 服务商帮忙写代码么。
|
 |
82
sueslee 2017-01-24 01:31:35 +08:00
lower 是啥
|
|
83
hcymk2 2017-01-24 01:34:54 +08:00
|
|
84
noli 2017-01-24 01:47:52 +08:00
@hcymk2 你贴的 Google 和 Amazon 的例子难道不就是 Http Status Code + Json 的好例子么？你从哪里看到他们告诉你返回的都是 200 ？
|
|
85
hcymk2 2017-01-24 02:14:16 +08:00
@noli
Google drive 例子 body 里面的 code 是什么? s3 drive 例子 body 的 code 是什么? 不能只靠 HTTP response status codes 而且 google drive 是 HTTP error codes and messages in the header |
|
86
noli 2017-01-24 02:35:53 +08:00 via iPhone
@hcymk2 对啊，所以只要被 Api 处理到了就返回 200 ，这不是大厂推荐的做法啊，保持返回 200 就是我反对的，你有什么意见吗？
|
|
87
mhycy 2017-01-24 03:01:51 +08:00
|
 |
88
changwei 2017-01-24 03:49:15 +08:00 via Android
这个公司既然都是招这种水平的人，说明楼主入职之前对公司调研不够啊。
|
|
90
noli 2017-01-24 10:36:44 +08:00 via iPhone
@mhycy web 场景下我也没觉得 200+json 有什么特别的优势。当然啦，受制于国内的实际情况--很多 web 前端只是半桶水，不喜欢上 https 甚至 https 据说也被劫持--用 200+json 的好处也就就是能适应这种状况了，但非要说这是优势的话，我想起了这笑话: 中国人最大的特质是什么？贫穷。
|
|
91
noli 2017-01-24 10:39:11 +08:00 via iPhone
@Symo 觉得不屑与我讨论就请拉黑加屏蔽，众目睽睽之下拉坨屎你这是干嘛呢？好了，现在屎拉到我身上了，满足了你奇葩的虚荣心了吗？
|
 |
92
chairuosen 2017-01-24 11:18:59 +08:00
@noli 如果你只用 HTTP STATUS CODE ，如果业务错误类型多于 HTTP STATUS 类型，而前端又想区分出错误类型，怎么办。
|
|
93
noli 2017-01-24 11:52:23 +08:00 via iPhone
@chairuosen 我没有说过只用 http status code 。我是反对，无论 api 如何处理 请求都返回 200 。
|
|
94
chairuosen 2017-01-24 12:04:34 +08:00
@noli 那就相当于有两个 code 字段了。 http status code 只是 json 中 code 的子集，所以前端肯定只用 json 中的 code ， http status 变成了冗余字段
|
|
95
noli 2017-01-24 12:08:42 +08:00 via iPhone
@chairuosen 只有不懂 rfc 威力的人才敢说 http status code 是冗余字段，理由我说了，全是 200 的话，你就别指望中间节点替你做进一步优化。再简单一点的例子，一堆客户端上为你做请求监控和警报的库也废掉了
|
|
96
chairuosen 2017-01-24 12:14:44 +08:00
@noli 这一点确实没考虑到
|
|
98
noli 2017-01-24 13:35:53 +08:00
@mhycy 主要是你得出使用 200 + json 的结论依据，在我这里看来是说不通的：
你认为： 中间设备干扰 and HTTPS 也可能被劫持 and 非 200 HTTP 回复可能会被劫持，这是我从讨论中知道的你使用 200 + json 的理由。 我认为： 如果 HTTPS 都劫持，那么使用 200 + json 的做法，在大规模网络应用，是缺点多于优点。 我觉得确实没什么好讨论的，明摆着大厂都不用你的做法。 而如果你的业务够小，你喜欢怎么来当然都是 OK 的 --- 那不如更直接一点，直接在 80 端口上走自定义协议不是更好么，反正你也不需要 HTTP 的特别加持。 |
|
100
noli 2017-01-24 13:53:44 +08:00 1
@mhycy 总结 200 + json 对比较大规模 API 服务的缺点：
1. 对于会话层不友好：具体来说就是，譬如上面讨论说到的缓存控制， API 警报监控之类的应用，光这一点我觉得已经足够了。 2. 对于开发者不友好：如果使用你的 API 不仅仅是 web 端，还包括 移动端甚至别的端，那么你就要保证这些端都要有 解析 json 或者 xml 或者别的什么格式的能力，才能知道如何处理你的消息；这也意味着对更多的开发者来说，除了 HTTP 以外他们必须关注你的自定义格式，但是假如我仅仅是写一个小 demo ，我不关心出错信息，只想尽快跑通， json + 200 的做法，就给这种快速开发测试的需求制造了不必要的障碍。 事实上，如果你真的很关心浏览器使用 API 时受到的干扰，那么你完全可以用 open resty 之类的或者别的流水线，自己写一个简单的报文解析，根据 Agent 和 回复报文内容，将 Agent 是浏览器的 HTTP 回复 的 status 统一改成 200 |
Select Language