面试被问到 REST 规范优点怎么回答才能让面试官满意？

[zhoudaiyu]

我回答的是资源的定义和访问方式比较清晰，然后面试官说不遵循 REST 规范也可以定义清晰，比如创建一个用户 /api/…/createUser 。然后我又说到了减少前后端交流沟通的成本，因为被操作资源的 uri 给了基本的增删改查的 url 都不用多说前端就能明白，然后他说那接口文档也可以。我竟然无言以对，好像没啥毛病啊。然后他让我下去仔细想想。可是我理解这本身就是就是个规范，又不一定谁都适合啊….不知道 REST 规范有什么别的好处，大家说说？

我也没说有了REST规范就必须所有api都得按照这个啊，没有按照规范的设计就不行就是有缺陷的啊。就好比出了Springboot也不影响你用SSM啊，结合场景看不就完了，非得生搬硬套REST？

[uselessVisitor]

rest 我认为是某种动作用对应的请求，比如请求用 GET，修改用 PUT，删除用 DELETE

[zhoudaiyu]

@beichenhpy 这就算是我说的第一点吧

[Junzhou]

那个啥博士 2000 年写的那篇博士论文 我觉得优点的就是可以通过 http 动词实现变现层转换，表现层就是资源的不同展现形式。

[caliburn1994]

我也很好奇。

Spring Data Rest 的用法：
get,put,delete 单个 bean.

而多个 bean 的操作，往往是通过 /search/deletebyID, /search/updateById 的方式。并且没有规定批处理，如：批量插入。

我猜测啊，Rest 是方便编写 API 文档。。

[johnsona]

烦死了 暴打面试官

[caliburn1994]

因为 Spring 还有一个项目，叫 Spring Rest Doc，既然有这个项目，就是说明写文档啊 hi 是有必要的。而通过这个依赖写文档，似乎是相对简单一些。

[pusidun]

method 表示操作，url 定位资源
前者动词，后者名词

[Vegetable]

不必介怀这种问题，这就像是有 100 个正确选项的多选题，对方却只希望你回答某一个答案一样。

面试官应该先肯定你的回答，然后补充更多的信息和提示，来引导你说出他期待那个答案，从这个过程中来判断你的水平。

而不是这样举个反例来否定你的答案。

[zhoudaiyu]

@Junzhou 反正怎么说他都能举出反例 感觉像个杠精
@caliburn1994 批处理一般就是靠接口名去看了，这倒是没啥问题
@johnsona 感觉像个杠精啊
@pusidun 主要问好处是啥….
@Vegetable 杠精本精

[konakona]

REST 这种方式其实是方便约束和统一 API 设计，利用一些动词、复数词结合 method 做到一个目标可以有多个行为。

你也可以打趣的时候，在一些开发频次较高的产品迭代里，JSONAPI 也会是一个很有帮助的工具。

表达你对于整体技术敏锐度。

[Jooooooooo]

要我说 REST 缺点大于优点

[momocraft]

有一套用 resource id 和动词（ http method+path ）组织 API route 的模式，并有（来自 http 的）安全性和冪等性定义

反正比没指导乱写强，比如不应该用 get 请求下订单

[raaaaaar]

可以在一个路由下用不同的方法做不同的事啊，其实就是一个封装的思想吧，路由作为对象，方法就是操作。比如你说的 creareUser，用 POST，那 GET 这些不就没有意义了么，如果一个路由只用一个方法，太冗余了，接口太多，用文档这个问题根本就不能解决，因为哪怕完全没有规则，只要文档跟得上就没啥问题，但问题是文档可能一直跟上程序吗？有多少人会一直跟进？甚至有多少人会写文档？完全没有规范的文档怎么维护？这些不要成本么

[LeeReamond]

emmmm.....优点不多，批评不少这么回答？

[DoctorCat]

对于开发而言要充分利用 REST 语义简洁的优势嘛，例如：
CRUD for User：
POST /user
DELETE /user
PUT /user
GET /user

显著的降低开发与维护过程的认知负荷，大白话就是懂英文的人都好理解和维护，文档也好写甚至不需要文档。其他优势爱咋咋地。

[DoctorCat]

缺点：如果开放接口，给某些 lowb 的 B 端大客户，甲方爸爸的安全策略可能会限制 HTTP method 的使用… 所以别奉劝面试官耗子尾汁。

[jadec0der]

@DoctorCat 我不觉得 REST 能降低开发与维护过程的认知负荷，找个懂英文的人，你觉得

POST /user 和 /createUser
PUT /user 和 /updateUser

哪个更好理解？更别说还有 PUT /user 和 PATCH /user 的区别了

[jadec0der]

Roy Fielding 的那篇论文提了一个概念，你给一个用户一个 web 页面，不需要教他，他拿过来就会用，web page 是自解释的。但是给一个客户端一个 API 文档，它是无法自己学会怎么用 API 的，要有人理解文档并写对应的代码，客户端才知道要请求哪个 API 。API 不是自解释的。

在 REST 里，资源和操作被分开了，比如客户端请求一个 aaa，返回一堆 bbb，那客户端可以推测出要添加新的 bbb 资源，就要请求 POST /bbb，要删除一个 bbb 资源，就要请求 DELETE /bbb，要更新 bbb 资源，就要请求 PUT /bbb 或者 PATCH /bbb，客户端不需要理解 aaa 和 bbb 分别是什么玩意。在 REST 的模型中，资源可以是任意的东西，但是操作已经被限定了。这样如果有一个通用 REST Client，它就可以适用于所有编写得当的 REST API 。而这个通过不同的 HTTP 动词，改变资源状态的模型，就叫 Representational state transfer

说回现实世界的 REST，我觉得 Roy 的本意并没有得到实现，现在的 RESTful API 跟他的期望相距甚远，只是一个规范而已，并没有巨大的好处。

[binux]

优点是流行啊。

[chanchan]

我至今理解不了 rest 的好处

[drackzy]

照着八股背说一遍，再结合自己的项目吹一遍。

[baiyi]

REST 不是规范，它是一种架构风格，是在许多种架构中组合推导出来的，它的优点就是这些架构所能带来的好处，最终形成的架构风格是能满足互联网规模的分布式超媒体系统的需求。
而 RESTful 风格的 API 设计具体能带来什么好处，还是要根据这些来理解的。

[www5070504]

照他那么说那是啥都没必要了 写文档被 这么爱写文档的公司还是别去了

[www5070504]

他好像不明白沟通成本的含义和写文档是多恶心的一件事

[zgl263885]

统一规范，易于理解，减少沟通成本，便于自动化生成文档及测试用例，可复用很多现成的轮子，为业务实现提供现成的解决方案。我能想到的。

[MoRun]

来龙去脉说清楚嘛，REST 怎么产生的 -> 为了解决啥问题 -> 优缺点 -> 使用上的一些点 -> 这个问题的其它解法的对比 -> 发展的趋势

[bigShrimp8577]

这就是揪字眼，没必要去。你是去干活的还是去吹牛逼的

[leokino]

REST 可以达成 convention over configuration，在一套约定俗称的框架下定义好了资源马上就知道对应 CRUD 的 api 怎么操作，比翻查文档节约的时间不止一个数量级。不要谈说复杂的 api 操作怎么处理，那就不是 rest 需要解决的问题。

[456789]

你俩说的都对把，但是 rest 更好

[DoctorCat]

@jadec0der 你喜欢 createUser 和 updateUser，但没有命名规范的话，你的小朋友同事可以搞出个 addUser 和 modifyUser，你觉得这种随意命名，会有利于项目发展？

我猜是你们维护的 API 太少了，所以才觉得使用路由命名表义无所谓甚至是更方便自己理解。

[DoctorCat]

@leokino
@zgl263885
严重同意这二位同志的意见。

[Sparkli]

对于我来说，如果都遵守这种风格，比如 elasticsearch api，我使用 GET 请求任意 URL 都不用怕做错什么事，避免脑子一热删库删表改数据

[namelosw]

REST 的核心是 HEATOAS，不过这个要杠也能杠
动词，也能杠
缓存，也能杠

我知道了，是共识… 大家好巧不巧都已经用上了 REST，毕竟「**的共识也是共识」，所以就没好死不死发明类似形式，不然文档还得专门多写几页解释

说到底 REST 就是玄学，别人说啥都能杠回去