一个 uri 用 patch, 传一个 array of business operation 进去就行了

https://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/

很多人总觉得面试是倒在最后的难问题上面，但其实更多时候是前面没有表现到最好（但也没差到让面试官放弃），最后的困难问题是反场复活的，答的好的话评价就是“基础 or 工程 or 别的什么一般，但对某某困难的问题的思路很清楚，有潜力”，答的不好的话评价就是这也不够好那也不够好了

@kuoruan put 第二次可以扔个 403 之类的，主要是创建已知 url 的（单个）资源应该用 put，post 一般是向一个集合里提交一个资源（客户端无法控制 url ）让服务器返回 url

书院派 A
POST captcha/ {type: image}

200 {type: image, requestId, image, status: CAPTCHA_STATUS_INIT}

PATCH captcha/:requestId
{answer: 1234, status: CAPTCHA_STATUS_VERIFIED}

200 {type: image, requestId, image, status, answer, verifyResult: {passed: true/false, error: ...}}

note: 用更多字段表示状态以及后续追加的信息，用 PATCH 修改资源（状态） 表示验证语义

书院派 B
POST captcha/ {type: image}

200 {type: image, requestId, image}

PUT captcha/:requestId/answer
{code:1234}

201

GET captcha/:requestId OR captcha/:requestId/verify-result
{type: image, requestId, image, answer:{code:1234}, verifyResult:{passed: true/false}}

note: 用 sub resource 代表资源的不同部分，创建 sub resource 表示验证语义

老油条派：（ restful 反模式）
POST captcha/ {type: image}
POST captcha/:requestId/verify

POST 动词是典型的 restful 反模式， 胜在表达能力好，简单易懂，真香

----------

PS. 个人认为拉取 captcha 不应当用 GET，因为有副作用，不能缓存，也不应该在用户没有干涉的前提下重试

@mcfog 行为=>嫌疑

@psychoo 改变软件运行方式，违反 eula 就是破解。除非官方提供或认可，其他非官方提供的，和官方版本有区别的都有违反知识产权、不正当竞争、入侵信息系统等相关法律的行为。 和具体实现是否入侵无关。 比如扣扣保镖这种即使 0 入侵纯改 host 实现，一样是违法

大体上来说，面不如你的人，就是把问题问到超出他的能力范围然后看能不能教的会 /带的动他（当然也要看能力范围内的回答的质量）

面和你水平相仿的人就是看能不能和他愉快地探讨一些有难度的问题（注意 1.难点绝不应该在知识量上，2.即使是擅长面试的人，应对面试题中的难点的困难程度也是远远高于平时工作的，水平相似，你准备面试题，还面过几次别人的话，一个话题上“碾压”水平相仿的人是正常的，不要施加压力，而是有节奏地给提示引导对方思考）

而面比你厉害的人，基本就是“请开始你的表演”，然后不懂就问，看他能不能教会你

如果你觉得你做的事情都没有难点，换谁来都能做的一样好，那我招你干嘛？
如果你觉得你还是有一些长处的，做的事情还是有一些能比别人做的更好的，这就叫难点啊

能别把我的手淘莫名其妙切到农村版么，上次我十几分钟才反应过来不是卖家少是被切到农村淘宝了，又花了十几分钟才研究出来怎么切换回普通版

抱歉，现在不方便，你看下午四点方便吗？

顺便给这公司心理扣十分，电面不事先预约
电面最怕的就是对方没状态越面越紧张，毕竟我们找的是工程师，不是电话销售，隔着电话说不清楚东西很正常

众所周知，现在还没有 90 后能活过 30 岁

没有业务代码的迭代试错，哪里来大流量高并发给中间件施展空间？哪里来大数据给算法捣鼓？
没有成熟稳定的基础架构，怎么一周甚至一天发几个版本快速迭代业务？

不仅限于技术角色，QA 产品运营市场等等，都是互相支持互相协同的，都有各自的困难和挑战，傻逼都能拖后腿，牛逼都能带着团队一起前进

反正我觉得很多人默认管理比做事牛逼，做底层比做上层牛逼，是很短浅的认知

面试的时候如果要考 git (不推荐)，可以考虑问一下这串命令的三个毛病是啥

@Muninn HTTP 协议更不是规范了，你说用 600 状态码违反 HTTP 协议那是对的，用 200+body 内容表示业务状态完全符合 HTTP 协议，不符合 restful 风格而已

你觉得我不懂的话那就这样吧，祝你工作顺利

首先 restful 根本不是规范，而是设计风格
其次，你参考的大厂 API 是第三方整合用的 API，而很多人讨论的背景是自己公司做给自己人的场景
restful 是学术（或者说学院派）没错，但你怎么就觉得知乎是学术的？这个问题是学术的？我怎么看怎么觉得这个问题是工程角度的

工程问题并不是学术问题，不是是非黑白问题，而是权衡和折中的问题，我真的从没见过哪家的设计是 100%按照全套 restful / rfc 的东西来实现的，patch 方法 + `application/json-patch+json` 的修改接口看都没看到过，HATEOAS 的东西最多在分页里见过一点

程序员最讨厌的 2 件事

1、接手的代码没有注释
2、写注释

希望你没有这样的误区

“技术是无止境的，要了解业务” => “成为业务专家就可以不劳而获了，可以不用努力也不会被淘汰了”


实际上技术无止境，业务也一样无止境，成为业务专家的真正含义是可以适应甚至应该引领业务变化发展，技术也是，真正技术上做出深度的人反而不怕技术变化，学不动的是菜鸡，随便学学就会的是大佬，写出东西来让别人学的是大神

你说是电商也好金融也罢，如果你做客服体系，那技术上看本质是垂直 im，完全是社交的活。你说做社交，开始玩变现了卖会员也好特权也罢那完全就是虚拟电商。你做任何 c 端业务，给运营人员用的内部系统本质上就是 2b 的 oa，更别说做游戏了，内置电商金融社交没的跑