04 | 工整与自由的风格之争：SOAP和REST
该思维导图由 AI 生成，仅供参考
概念
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
SOAP 和 REST 是两种不同的网络通信风格，分别代表着工整与自由的风格之争。SOAP 是一种简单对象访问协议，关注数据对象传输的格式，通过 XML 格式的文本进行数据传输，而 REST 是一种为了信息在互联网上顺利传递而设计的软件架构风格，使用 HTTP 协议进行通信。SOAP 通过定义 XML 消息体来实现图书馆添加书本的需求，而 REST 则通过 HTTP 方法来代表增删改查的不同动作，体现了资源、表现层和状态转换这三个要点。SOAP 通常通过 HTTP POST 发送到对端，而 REST 使用 HTTP 方法来反映接口上将执行的行为。此外，文章还介绍了幂等性和安全性的概念，以及 HTTP 的一些其它方法。SOAP 和 REST 在概念层次上有所不同，但在风格层面上进行比较是可行而有趣的。SOAP 和 REST 分别代表着工整、严谨和细致，以及自由、灵活和简约的风格，它们在互联网上活跃并影响着新技术的诞生。 SOAP 明显是更“成熟”的那一个。它在数据传输的协议层面做了更多的工作，藉由 XML schema，它具备更严格的检查和校验，配合 WSDL，在真正发送请求前，几乎就对所有远程接口事无巨细的问题有了答案。但是，它的复杂度令人望而生畏，也是它最受人诟病的地方。REST 则相反，新接口的学习成本很低，只需要知道资源名称，根据我们熟知的规约，就可以创建出 CRUD 的请求来。但是直到真正发送请求去测试为止，并没有办法百分百确定远程接口的调用是否能工作，或者说，并不知道接口定义上是否有不规范、不合常规的坑在里面。 对于互联网来说，SOAP 已经是一项“古老”的技术了，晚辈 REST 似乎更切合互联网的潮流。在大多数情况下，REST 要易用和流行得多，于是很多人都不喜欢繁琐的 SOAP 协议。技术的发展总是有这样的规律，一开始无论问题还是办法都很简单，可是随着需求的进一步增加，解决的方法也缓慢演化，如 SOAP 一般强大而复杂，直到某一天突然掉到谷底，如 REST 一般返璞归真。 REST 通过 HTTP 方法实现本身，也受到了 HTTP 方法的局限性制约。比如最常见的 GET 请求，有时需要一个复杂的查询条件集合，因此参数需要结构化，而 GET 只支持一串键值对组合的参数传递，无法适应业务需要。对于这样的问题，有一些 workaround，比如使用 POST 消息体来传递查询条件的结构体，但那已经偏
《全栈工程师修炼指南》，新⼈⾸单¥59
全部留言(14)
- 最新
- 精选
八哥置顶早期后台接口之间调用Web Service时用的SOAP协议多，比如订单和供应商之间接口调用等。后续RESTful风格更轻量级，开发者工程师更愿意使用。配合api文档，解决了联调过程中，接口没有定义规范等问题。 userName不是唯一的，实际无法完成删除，delete是一个删除操作，不应该暴露在URL里面。 应该是:/users/xxx。xxx是userId，然后请求的method设置为：DELETE。作者回复: 感谢回答！回答正确。 第一个问题属于开放性的，当然，也有很多可供比较的其它方面。 对于删除用户的接口设计，回答得非常全面： （1）动作要以 HTTP 方法体现出来，而不是放在 URL 里面； （2）要使用 userId，而不是 name，userId 才是唯一的。 （3）资源使用复数“users”，完全正确。
2019-09-1817
leslieRESTFUL设计删除单个用户"http://xxx/deleteUser?userName=James"的问题如下：1)get/put/post/delete不是应当接完后再加/再去跟具体的么？至少应当改成"http://xxx/delete/userName/James" 2)其实这种具体的值不应当直接放到这里：我记得当年自己做开发的时候就不会允许暴露账号信息的 其实那里直接写到"http://xxx/delete/userName"样子就不会再在HTTP里面看到了；当年经典的SQL注入不就是全部明文写在里面了么。 REST架构和风格这块我在开课时曾说过希望能改善自己Coding的问题：按照老师REST那块的Coding演示：其实username=James应当放到Content-Type: application/json里面并且写出username:James;HTTP部分只到"http://xxx/delete/username"这样就OK了；翻阅了一些网站现在的写法，发现大多类似；具体答案：等待老师的揭晓。 谢谢老师的分享：期待下节课的内容。作者回复: 感谢回答！ 严格来说，行为应当放到 HTTP 方法中去，而不是 URL 中。还有使用 userName 本身的问题，你可以看一下另一位朋友的回答。当然，现在不少接口其实并不是很符合 REST 风格的，方法放在 URL 中就是其中一个方面。至于不允许暴露账号信息是特殊的业务需要，能想到这一点非常好，但它并非 REST 的要求。
2019-09-184
GopherRESTful 风格的API：（系统接口：正交化，统一化/标准化，结构化） 1.正交化资源（名词）和动作（动词） 2.资源的描述要统一（URI），先模块/位置，再资源/标识符，最后可以附加简单的参数（?x="y"#label）。复杂的参数应当结构化，通过Header传递 3.动作要标准化（AEMR等有限集合），个性化需求可以通过API查询接口获取/协同 函数风格的API：（模块接口：正交化，结构化，模型化） 1.动词作为函数名，名词作为参数（正交化） 2.常见类型的参数（数量也不能太多）可以简单罗列，复杂的参数应当结构化为对象来传递，参数太复杂或数量太多时就需要考虑拆分函数（结构化） 3.函数存在于模块里面，它的目的是实现DSL（模型化），自然不能标准化。但它操作的对象相对单纯，因此函数语义（主要通过通过函数名称表达）相对更加明确，可以实现言简意赅作者回复: 👍
2019-09-2023
William Ning「，至于 HTTP，它是 REST 风格的重要载体。重要，但不是唯一，因为载体并不只有 HTTP 一个，比如还有 HTML 和 XML，」http与html xml这里适合放在一起类比吗？这里他们是阶段组合的关系，而非可相互取代的关系？若老师看到，望解答，谢谢作者回复: 好问题。 我解释一下文中的含义：你理解得没错，它们是互相组合的关系，而非取代的关系。 进一步展开说，当载体体现的是它上面的数据的时候，就是 HTML、XML 或者 JSON 它们关心的了。我们在讲 REST 的时候，特别是设计 REST 风格的接口的时候，我们并不是到 HTTP 层面就戛然而止了，我们还会继续设计消息体，这就往往会提到这三者之一。
2019-09-261
靠人品去赢（1）两种都用过，之前在银行类使用过webservice，就是很典型的，就是约定好字段一个不多一个不少按照WSDL上来。后面公司用的是Rest，看文档反正你要的我都给你了，需求变更也不怕反正能满足你就是了。 （2）参数选择不对，命名不规范，用户名称不是唯一的很可能重复，即使是唯一的，博大精深的汉字也能教育你，可能某个系统编码库不全，一些少见的字造成不必要的麻烦，什么飞龙在天的䶮可能结果是不一样的。还有接口命名，先是模块再是功能，如users/deleteUserById?id=XXX。看过一本书给的建议命名是不要怕长，总比看上去提示太少一脸懵逼强。 老师对命名有没有理解，之前没注意过现在虽然有意识的修改，争取见词知意，但还是有些没做好，像前一阵包名有大写字母和下划线被人吐槽看着蛋疼。作者回复: 接口命名方面，没有统一的标准，但你可以看看第五讲扩展阅读的 AnyAPI，看看其他人是怎么做的，大多数接口服务的命名风格是一致的。
2019-09-201
松松米用过，但如果米理解错的话，RESTful风格是用URI标识要操作的资源，用HTTP请求行为表示要对资源执行的动作，所以delete这个“行为”不应该出现在URI里吧，总不能get这个用户和del这个用户操作的还是不同的资源？作者回复: 对，行为不能出现在 URI 里面，你可以看一下另一位朋友 的回答。
2019-09-181
不要挑战自己的智商为什么rest URL都是名词？如果有动词有什么不好？作者回复: 这是为了符合RESTful的规则。既然是资源，天然地，它就是名词。你可以针对某一个特定的资源实体做CRUD的操作，如果是一个动词，这就说不通了。
2020-08-072
leslee为什么删除操作是幂等性的...作者回复: 在使用唯一的 id 去删除指定资源时，删除多次和删除一次效果一样
2019-11-17- William Ning关于幂等性，文中说的是服务端的数据状态不变，但是「从表格中你可以看到，创建资源单位不是幂等的，执行多次就意味着创建了多个资源单位，而其它操作都是幂等的。」这个是按照数据量来衡量的吗，如果是这样，那删除操作怎么是幂等的？望老师看到解答。
作者回复: 好问题。 我来解释一下文中的意思。“幂等”的效果是，执行了多次和执行一次的效果一样，而 REST 通常的删除设计都是基于唯一 id 的，因此从这个角度来说，删除多次，确实和删除一次是一样的，因为只有一次是完成了真正的删除。 但是创建就不是了，因为创建的时候，REST 的设计往往是不提供这个唯一 id 的（唯一 id 是服务端自动生成的），那么如果提交多次，就变成了创建了多个对象。
2019-09-263 
许童童项目中用的基本上都是REST，我觉得用SOAP的只有以前遗留下来的代码了。作者回复: SOAP 还是常有使用的，特别是一些电信软件、传统软件等领域。当然，确实 REST 更常见。
2019-09-18
