全栈工程师修炼指南
熊燚(四火)
Oracle首席软件工程师
立即订阅
2286 人已学习
课程目录
已更新 43 讲 / 共 40 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 从成长角度看,为什么你应该成为全栈工程师?
免费
学习路径 | 怎样成为一名优秀的全栈工程师?
导读 | 如何学习这个专栏?
第一章 网络协议和 Web 接口 (6讲)
01 | 网络互联的昨天、今天和明天:HTTP 协议的演化
02 | 为HTTP穿上盔甲:HTTPS
03 | 换个角度解决问题:服务端推送技术
04 | 工整与自由的风格之争:SOAP和REST
05 | 权衡的艺术:漫谈Web API的设计
06 | 特别放送:北美大厂如何招聘全栈工程师?
第二章 欢迎来到 MVC 的世界 (7讲)
07 | 解耦是永恒的主题:MVC框架的发展
08 | MVC架构解析:模型(Model)篇
09 | MVC架构解析:视图(View)篇
10 | MVC架构解析:控制器(Controller)篇
11 | 剑走偏锋:面向切面编程
12 | 唯有套路得人心:谈谈Java EE的那些模式
13 | 特别放送:选择比努力更重要
第三章 从后端到前端 (7讲)
14 | 别有洞天:从后端到前端
15 | 重剑无锋,大巧不工:JavaScript面向对象
16 | 百花齐放,百家争鸣:前端MVC框架
17 | 不一样的体验:交互设计和页面布局
18 | 千言万语不及一幅画:谈谈数据可视化
19 | 打开潘多拉盒子:JavaScript异步编程
20 | 特别放送:全栈团队的角色构成
第四章 数据持久化 (7讲)
21 | 赫赫有名的双刃剑:缓存(上)
22 | 赫赫有名的双刃剑:缓存(下)
23 | 知其然,知其所以然:数据的持久化和一致性
24 | 尺有所短,寸有所长:CAP和数据存储技术选择
25 | 设计数据持久层(上):理论分析
26 | 设计数据持久层(下):案例介绍
27 | 特别放送:聊一聊代码审查
第五章 寻找最佳实践 (6讲)
28 | Ops三部曲之一:配置管理
29 | Ops三部曲之二:集群部署
30 | Ops三部曲之三:测试和发布
31 | 防人之心不可无:网站安全问题窥视
32 | 和搜索引擎的对话:SEO的原理和基础
33 | 特别放送:聊一聊程序员学英语
第六章 专题 (7讲)
34 | 网站性能优化(上)
35 | 网站性能优化(下)
36 | 全栈开发中的算法(上)
37 | 全栈开发中的算法(下)
38 | 分页的那些事儿
39 | XML、JSON、YAML比较
40 | 全栈衍化:让全栈意味着更多
全栈工程师修炼指南
登录|注册

04 | 工整与自由的风格之争:SOAP和REST

四火 2019-09-18
你好,我是四火。
今天我要邀请两位风格迥异的主角登上舞台,一位西装革履,另一位随性洒脱。前面那位,代表着工整、严谨和细致;后面那位,代表着自由、灵活和简约。
它们来自两个不同的时代,却同时活跃于当今的互联网,并担当着重量级的角色,影响了一批新技术的诞生。今天,就让我们来认识下它们,它们的名字,分别叫做 SOAP 和 REST。

概念

SOAP,Simple Object Access Protocol,即简单对象访问协议,定义了数据对象传输的格式,以便在网络的节点之间交换信息。你可能会问,HTTP 不就是干这事的吗?其实,它们都在 OSI 7 层模型的应用层上,但却互不冲突,SOAP 并不依赖于 HTTP 而存在,而且它们可以互相配合。
HTTP 负责信息的传输,比如传递文本数据,关心的是消息的送达,但却不关心这个数据代表着什么。这个数据可能本来是一个内存里的对象,是一篇文章,或者是一张图片。但是 SOAP 恰恰相反,它关心的就是怎样把这个数据给序列化成 XML 格式的文本,在传输到对端以后,再还原回来。
用一个形象的比喻就是,消息传输就像快递,HTTP 主要关心的是信封,而 SOAP 主要关心的是信封里的物件。今天我们讨论的 SOAP,不仅仅是协议本身,更主要的是它的风格。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《全栈工程师修炼指南》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(12)

  • 八哥 置顶
    早期后台接口之间调用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-18
    7
  • leslie
    RESTFUL设计删除单个用户"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-18
    3
  • ning先森
    「,至于 HTTP,它是 REST 风格的重要载体。重要,但不是唯一,因为载体并不只有 HTTP 一个,比如还有 HTML 和 XML,」http与html xml这里适合放在一起类比吗?这里他们是阶段组合的关系,而非可相互取代的关系?若老师看到,望解答,谢谢

    作者回复: 好问题。

    我解释一下文中的含义:你理解得没错,它们是互相组合的关系,而非取代的关系。

    进一步展开说,当载体体现的是它上面的数据的时候,就是 HTML、XML 或者 JSON 它们关心的了。我们在讲 REST 的时候,特别是设计 REST 风格的接口的时候,我们并不是到 HTTP 层面就戛然而止了,我们还会继续设计消息体,这就往往会提到这三者之一。

    2019-09-26
    1
  • Gopher
    RESTful 风格的API:(系统接口:正交化,统一化/标准化,结构化)
    1.正交化资源(名词)和动作(动词)
    2.资源的描述要统一(URI),先模块/位置,再资源/标识符,最后可以附加简单的参数(?x="y"#label)。复杂的参数应当结构化,通过Header传递
    3.动作要标准化(AEMR等有限集合),个性化需求可以通过API查询接口获取/协同

    函数风格的API:(模块接口:正交化,结构化,模型化)
    1.动词作为函数名,名词作为参数(正交化)
    2.常见类型的参数(数量也不能太多)可以简单罗列,复杂的参数应当结构化为对象来传递,参数太复杂或数量太多时就需要考虑拆分函数(结构化)
    3.函数存在于模块里面,它的目的是实现DSL(模型化),自然不能标准化。但它操作的对象相对单纯,因此函数语义(主要通过通过函数名称表达)相对更加明确,可以实现言简意赅

    作者回复: 👍

    2019-09-20
    1
    1
  • 靠人品去赢
    (1)两种都用过,之前在银行类使用过webservice,就是很典型的,就是约定好字段一个不多一个不少按照WSDL上来。后面公司用的是Rest,看文档反正你要的我都给你了,需求变更也不怕反正能满足你就是了。
    (2)参数选择不对,命名不规范,用户名称不是唯一的很可能重复,即使是唯一的,博大精深的汉字也能教育你,可能某个系统编码库不全,一些少见的字造成不必要的麻烦,什么飞龙在天的䶮可能结果是不一样的。还有接口命名,先是模块再是功能,如users/deleteUserById?id=XXX。看过一本书给的建议命名是不要怕长,总比看上去提示太少一脸懵逼强。

    老师对命名有没有理解,之前没注意过现在虽然有意识的修改,争取见词知意,但还是有些没做好,像前一阵包名有大写字母和下划线被人吐槽看着蛋疼。

    作者回复: 接口命名方面,没有统一的标准,但你可以看看第五讲扩展阅读的 AnyAPI,看看其他人是怎么做的,大多数接口服务的命名风格是一致的。

    2019-09-20
    1
  • 松松
    米用过,但如果米理解错的话,RESTful风格是用URI标识要操作的资源,用HTTP请求行为表示要对资源执行的动作,所以delete这个“行为”不应该出现在URI里吧,总不能get这个用户和del这个用户操作的还是不同的资源?

    作者回复: 对,行为不能出现在 URI 里面,你可以看一下另一位朋友 的回答。

    2019-09-18
    1
  • leslee
    为什么删除操作是幂等性的...

    作者回复: 在使用唯一的 id 去删除指定资源时,删除多次和删除一次效果一样

    2019-11-17
  • ning先森
    关于幂等性,文中说的是服务端的数据状态不变,但是「从表格中你可以看到,创建资源单位不是幂等的,执行多次就意味着创建了多个资源单位,而其它操作都是幂等的。」这个是按照数据量来衡量的吗,如果是这样,那删除操作怎么是幂等的?望老师看到解答。

    作者回复: 好问题。

    我来解释一下文中的意思。“幂等”的效果是,执行了多次和执行一次的效果一样,而 REST 通常的删除设计都是基于唯一 id 的,因此从这个角度来说,删除多次,确实和删除一次是一样的,因为只有一次是完成了真正的删除。

    但是创建就不是了,因为创建的时候,REST 的设计往往是不提供这个唯一 id 的(唯一 id 是服务端自动生成的),那么如果提交多次,就变成了创建了多个对象。

    2019-09-26
    2
  • OnFire
    目前外包在银行做供应链业务,soap与restful混用,新接口基本都不用soap了,像soap这种结构相对复杂的方案会逐渐被淘汰吧,restful更简单明了
    2019-09-19
  • anginiit
    之前一个项目 ws和rest都有用到,rest是自己项目前后台请求使用,ws是请求第三方的接口使用。只是停留在使用阶段 还没有深入的了解过,借着这一课 认真学习下。
    2019-09-19
  • 许童童
    项目中用的基本上都是REST,我觉得用SOAP的只有以前遗留下来的代码了。

    作者回复: SOAP 还是常有使用的,特别是一些电信软件、传统软件等领域。当然,确实 REST 更常见。

    2019-09-18
  • sky
    项目中基本上用的都是restful。soap用着别扭

    作者回复: 为什么别扭?:)

    2019-09-18
    1
收起评论
12
返回
顶部