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

[zhoudaiyu]

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