- 我是一个线程(修订版)
- 我是一个 Java class
- Javascript:一个屌丝的逆袭
- Java : 一个帝国的诞生
- JSP 一个装配工的没落
- TCP/IP 之 大明王朝邮差
- TCP/IP 之大明内阁
- TCP/IP 之蓟辽督师
- CPU 阿甘
- CPU 阿甘之烦恼
- CPU 阿甘:函数调用的秘密
- 我是一个网卡
- 我是一个路由器
- 我是一个进程
- 我是一块硬盘(上)
- 我是一块硬盘(下)
- 我是一个键盘
- 张大胖的 socket
- 张大胖学递归
- 学习面向对象的令狐冲
- 张大胖学数据库
- 数据库村的旺财和小强
- 小李的数据库之旅(上)
- 小李的数据库之旅(下)
- 漫画:什么是机器学习?
- 那些烦人的同步和互斥问题
- IE 为什么把火狐和 Chrome 给打伤了?
- 对浏览器村的第二次采访
- 节约标兵 IE 的自述
- EMail 诞生记
- Email 诞生记(下)
- Http 历险记(上)
- Http 历险记(下)-- Struts 的秘密
- 动物王国的面向对象
- 冯·诺伊曼计算机的诞生
- Http Server : 一个差生的逆袭
- 张大胖的加法器
- 从 1 加到 100:一道简单的数学题挑战下你的大脑
- 编程语言
- Javascript:一个屌丝的逆袭
- 计算机语言之战
- 我和编程语言的爱恨情仇(上)
- 我和编程语言的爱恨情仇(下)
- Android 为什么选择了 Java
- iOS 为什么选择了 Object-C?
- Basic : 一个老兵的自述
- Node.js : 我只需要一个店小二
- 命令式编程 vs 声明式编程
- 编译还是解释?
- 程序人生
- “架构师"小赵
- 师兄说
- 师姐说
- 小王的架构师之路
- 小李的版本管理系统
- 小超穿越记
- 小李的 Build 之路(上)
- 小李的 Build 之路(下)
- 张大胖改 Bug
- 我的编程之路--大学趣事
- 码农小王的一天
- 小李在外企
- 张大胖的需求估算
- 从厨师到码农
- 聊一聊那些神一样的程序员们(上)
- 聊一聊那些神一样的程序员们(中)
- 聊一聊那些神一样的程序员们(下)
- 谁是互联网之父?
- 一个价值百万的创业教训
- 让自己与众不同 - 提升工作的价值
- 看看你的“易燃性”
- 从无聊的工作中寻找价值
- 什么样的学生适合报考计算机?
- 谈谈程序员的职业方向(上)
- 谈谈程序员的职业方向(中)
- 谈谈程序员的职业方向(下)
- 谈谈培训班的作用
- 码农需要知道的“潜规则”
- 学习编程的加速度
- 码农在工作中的必备能力
- 码农和英语
- 老司机经验
- 假如时光能够倒流, 我会这么学习 Java
- 假如我是计算机系老师
- 学会编程, 而不是学会 Java
- 从增删改查中突围
- 抽象:程序员必备的能力
- 懒就一个字
- 编程的自学方法
- 小王买房记
- 从一道面试题谈谈一线码农应该具备的基本素质
- 想写框架的看过来
- 苹果手机变砖头以后
- 如何快速的学习一门技术?
- 唯一不变的是变化: 谈谈微信应用号
- 什么是企业应用?
- 勿以浮沙筑高台
- 为什么敏捷开发难于成功?
- localhost vs 127.0.0.1
- GitHub/Stackoverflow 找工作时有什么用?
- 动词 or 名词 :这是一个问题
- 如何选择入行语言
- 有时候,沉默是金
- 零 Bug 的代码是怎么炼成的?
- 浮点数为什么不精确?
- 文章错误大全
- Open Source--不要为了开源而开源
- 一不留神,代码就腐化了
- 先做个“键盘侠”, 再来写程序
- 不加断点调试的程序员是好程序员
- 码农必备技能:烂代码的处理之道(上)
- 码农必备技能:烂代码的处理之道(下)
- 学习数据结构有用吗?
- 从现在开始,丰富你的简历
- 那些永不过时的书,你看过几本吗?
- 学好编程必备的一个品质你知道吗?
- 你最爱的 Java
- 搞懂了这几点,你就学会了 Web 编程
- Spring 的本质系列(1) -- 依赖注入
- Spring 本质系列(2)-AOP
- 三层架构和 MVC 那点事儿
- Java 帝国之拨云见日识回调
- 小张的 Duck Typing
- JDBC 的诞生
- JDBC 后传
- 一个不安分的 JDBC 驱动
- Java 帝国之 Java bean (上)
- Java 帝国之 Java bean(下)
- Java 帝国之函数式编程
- Java 帝国之函数式编程(下)
- 关于 Java 初学者需要知道的 10 件事
- JUnit 你不知道的那些事儿
- 圣诞礼物:Java EE 的历史
- Java EE 读书指南
- 给小白的 Java EE 指南
- 给小白的 Java EE 指南(2)
- 给小白的 Java EE 生存指南(3) : XML
- 给小白的 Java EE 生存指南(4) : 一只叫 Tom 的猫
- 给小白的 Java EE 指南(5) : AJAX
- 给小白的 Java EE 生存指南(6) :Java 反射
- 闲聊
- "饿了么"初体验
- 来自大脑的控诉
- 一个高中生是怎么玩自媒体的?
- 尝试 分答
- 到底应不应该上培训班?
- 自学编程中遇到问题怎么办?
- 据说 99%的初级程序员看完后都不迷茫了
- 一行代码引发的“血案”
- 对一个死锁问题的思考
- 通过外包进入名企
- 请开往十年前的今天
- 为什么自学中最好有个师傅指导一下?
- 这个网站值得你花时间投入
- 为什么你无法坚持自学编程?
动词 or 名词 :这是一个问题
前言:有网友让我用通俗的语言来讲一讲 RESTful , 我在这一块工程实践的不太多,有点为难了, 只能讲一讲我的理解, 欢迎大家批评指正。 计算机行业最擅长造新词了,像什么 AJAX,IoC, AOP, SOA, NoSQL, 微服务,TDD,敏捷,RESTful......等等。
有很多人非常喜欢在口头拽这些热门名词,显得多么高深的样子, 其实这些热词背后代表的东西,要解决的问题没那么复杂,很多人是由于带着敬畏心被吓住了。
RESTful 就是其中之一, 它不是一个新的计算机语言或者技术, 只是一个 架构风格 , 准确一点讲是 如何设计系统来对外提供服务 。
传统网站 我在 2000 年左右还是微软粉丝,一直用 ASP + COM 写 Web 网站, 当时的网站是单纯的 HTML, 只有一点 javascript 效果, 这些网站基本上是自治的“独立王国”, 不会通过 API 接口对外提供服务。
由于在浏览器中通过 javascript 来异步访问后端接口的极少, AJAX 这个热词还没有出现, 所以当时在 ASP 中主要处理两个东西: 图 1 : 常见的网站操作 很普通,对吧? 其实现在大部分网站还是这么做的。 SOA 后来互联网大发展, 各个网站系统变的越来越复杂,一个自治的“帝国”经常要被划分成多个“王国”,这些王国之间如何沟通和交流变得重要起来。
一些大厂商顺势制定了叫做 SOA 的标准,提出了面向服务的架构体系。
和 面向对象 这样的技术术语不同 , SOA 中的服务其实是 业务层面 的东西, 是个 业务活动的逻辑表达方式 ,粒度更粗一些。
这些服务独立于厂商,产品和具体实现技术, 能够发布出来被别的系统调用, 还能够被组合起来形成更粗粒度的“服务”。
虽然服务是面向业务的, 但还得用具体的技术表达出来, 毫无意外, 大佬们选择了 XML, 用 XML 来描述一个服务看起来来像这个样子:
图 2: 服务描述片段
没有玩过 Web Service 的不用完全看懂它,它描述的也是一个 getBook 这样的操作, 输入是一个 id ,类型是字符串。
返回值也是一个字符串 (通常是 XML 格式的,表示书籍的详细信息)
我想突出的重点是这个服务( getBook )和 “图 1" 中的 getBook.action 在形式上的一致性:
他们都试图表达这样一个过程: 获得一本书的信息, 所以这两种方式都是 面向过程 的。 或者说,他们都以 动词 为主, get Book, add Book, delete Book , place Order, register User, login , transfer 等等 。
RESTful 其实面向过程,以动词为主的方式是最自然的方式, 码农不用怎么费脑子就能想到如何设计。
然后 RESTful 这种概念就漂洋过海,从美国杀入了中国市场。
RESTful 告诉大家说: 以后你们不要用动词, 用 名词 更好, 不要面向过程了, 要 面向资源(Resource)。 资源使用一个 URI 来表达的, 例如 : 图 3 : REST 风格的资源
注意图 3 中的 books, orders, 这些都是名词, 那问题自然就来了: 我怎么做传统的 add, delete 等操作呢?
RESTful 说: 要充分利用 HTTP 提供的方法: 图 4: 对资源的操作
你看增删改查都齐全了。
需要注意的是服务器端返回信息的格式由发起调用的客户端指定,例如 HTML ,JSON, XML, 这称为资源的表述(representation)
我第一次看到这种方式的时候大为震惊, 这实在是太不直观了。
按照这种风格,你需要把服务器端的东西都 ” 资源化 “, 像上面的那些很容易, 还有一些例如 转账 , 登录 , 忘记密码 , 获取短信验证码 ,这样常见的业务操作“资源化”起来就不那么爽了。
RESTful 架构风格还要求 Stateless(无状态) , 服务器端并不会维护/保存会话(session) 信息, 这些会话信息应该有客户端来维持,每次请求时也需要一并发送到服务器端。
服务器端甩掉了会话状态这个大包袱,一下子就轻松多了 ,可扩展性会有极大提升, 例如我可以把一个服务部署到由 100 个服务器组成的集群中,每个服务器都可以处理用户的请求。
假设用户第一个请求发到了服务器#87 ,然后这个服务器坏了, 第二次请求可以发送到剩下 99 个服务器中的任何一台, 反正会话信息包含在每个请求中,任意一台服务器都能处理。
我认为 RESTful 的无状态是一种理想的境界,现实中不大容易做到, 客户端到底如何保存 session 信息呢,是每次请求都把用户名/密码 发到服务器端还是通过第三方认证的方式实现?
如果想实现一个购物车的应用, 服务器不保存 session 的话该怎么做? 我这块儿实践不多,请高手不吝赐教。
虽然有难度, 那为什么现在很多人对 REST 趋之若鹜呢?
我个人认为大家是看中了他的 轻量级的风格 , 那就是用 HTTP+JSON 就可以搞定一切。
传统的 SOA 倾向于用 WSDL 来描述服务, 用 SOAP 协议来访问服务,此外还有服务注册,发现, 组合,总线,安全等一系列问题, 通常还得上 Websphere ,WebLogic 这样重量级的服务器。
码农不仅要问了: 我就想调用一个简单的接口, 搞这么麻烦干嘛?
REST 一来, 写个 Web 服务简直是太简单了, 用一个最“低级”的 java servlet, 分分钟搞定, 不过有时候大家也没有严格的遵循 REST 的要求, 没有把一切东西都“资源化”,因为那样太不容易了。
我看到的很多项目号称是 REST 风格, 但其实就是通过 HTTP 和 JSON 对外提供的服务而已 ,没有完整的遵循 REST 架构风格的约束, 可以说是“挂着 REST 的羊头,卖着面向过程的狗肉”。
最后,推荐大家去读一下 RESTful 架构风格的提出者 Roy Fielding 博士的论文, 2000 年发表的《 架构风格与基于网络的软件架构设计 》, 这是 RESTful 开山之作, 也是 Web 发展史上非常重要的一篇文献。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论