我画了个图，读者朋友可以感想熏染下，自己作为用户，要求自己代码编出来的页面，岂不是很有造诣感？

如果你作为用户来访问互联网资源，那么大概的过程是这样的：你在浏览器是录入 URL 或者点击一个超链接后，浏览器会要求 DNS 做事器解析这个 URL，返回域名映射的IP，然后通过 HTTP 要求这个 IP 对应的 web 资源，如果涉及到一些数据的查询，还会访问数据库做事器获取数据，然后把数据返回，web 做事器将数据和样式处理下，转成 web 资源，然后返回给浏览器，经由浏览器的渲染，你就能看到可视化的页面了。

但那时搞 web 编程还比较麻烦，什么 JSP，ASP，前端代码和后端代码杂糅在一起，就这么你离不开我我离不开你似的在 web 做事器上跑着，代码看上去不清爽，很多业务逻辑也没法被其它站点复用。

jsp和rest我是若何废弃 JSP转向 REST 编程的 SQL

假设现在有三个巨子企业，他们分别掩护 baitu.com，kk.com，taopao.com 三个站点，这些站点向做事真个交互都是通过 JavaScript 客户端实现的。
某一天三家合并了，那就会涉及很多业务互通，比如 baitu.com 站点下想访问 kk.com 的一些数据。

这时候该怎么做呢？过去通用的解法是用 SOAP（Simple Object Access Protocol，大略工具访问协议），这是一种基于 XML 格式以及 HTTP 传输办法的数据交流协议。

前端 JavaScript 是不能直接访问 SOAP 做事的，须要先访问到 baitu.com 对应的网站后台，然后由网站后台去访问 kk 供应的 SOAP 做事（要在之前网站后台直接访问数据库的逻辑上，抽取单独的做事层出来），然后再由 baitu.com 的网站后台对返回的数据进行渲染，将 HTML 等资源信息返回给前端。

那么这时候问题就来了，我在 baitu.com 上的一个前端页面上，一旦想加点 kk 才有的数据，我就必须得改 baitu.com 的网站后台，并且要重新接入 kk 供应的 soap 做事。
这显然是一种低效的架构办法，相称影响研发效率。

那么有没有一种办法，我不须要经由 baitu 的网站后台，直接就能访问到 kk 的做事呢？页面上业务逻辑的处理，就不要放网站后台了，在 JavaScript 的客户端直接做掉，通过访问后真个某种做事得到业务处理的结果，然后基于网站后台存放的 HTML 和 CSS 来渲染页面。

就像图示的这样，baitu 的 JavaScript 客户端就做两件事，访问后端做事获取业务逻辑处理的结果数据，将数据以 网站后台存放的 HTML 和 CSS 的哀求展示出来。
这样看来，网站后台就像个壳，只卖力本站的 HTML、CSS 和 JavaScript 等静态资源，干系的业务逻辑处理就交给做事来供应。

这便是前后端分离的思想，前端静态资源和后端动态做事解耦。
前端只关心 HTML 等前端代码，不涉及一行后端代码，后端只关心自己供应的做事，不涉及一行前端代码。

在这种思想的指引下，SPA（single page web application，单页面运用）就涌现了。
SPA 是单个 HTML 页面的 Web 运用程序，它在用户与运用程序交互时由 JavaScript 动态更新页面。
其事情事理如图。

浏览器客户端一开始会加载必需的 HTML、CSS 和 JavaScript，之后的所有的操作都在这张页面上完成，由 JavaScript 来掌握，通过某种数据格式和做事端产生交互，获取返回结果。

这个时候，客户端就须要做事端供应的业务做事得是一个 API(运用程序访问接口)，客户端可以直接发起要求，这时候 REST API 就派上用场了。

什么是 REST 呢？

REST 是 REpresentational State Transfer（表述性状态转移） 的首字母缩写，这名字什么鬼？好难明得的样子，不过它本身就源于国外一个博士的论文，论文嘛，大家都知道的，一样平常不太好理解。
我这里画了个图，通过分拆的办法，帮助大家理解下：

REST 是一种设计思想，它的核心是资源，可以理解成在 REST 的天下里，万物皆资源。

REpresentational（表述性）：这是个形容词，它想要表达的意思是，资源可以用各种形式来进行表述，无论是 XML、JSON 还是 HTML，只要适宜资源利用者，任何形式都可以。
State（状态）：这是个名词，也是 REST 思想的实质。
它见告开拓者，REST 关注的是资源当前的状态，而不是对资源采纳的行为。
无论资源的形式如何变革，它要表达的内容实在是统一的，该资源存在还是不存在，单个信息还是多个信息，都有哪些属性，这便是资源的状态。
Transfer（转移）：这是个动词，它指转移资源，以某种表述性形式把资源从一个运用转移到另一个运用。
转移过程中，资源状态可能会有所变革。

在 REST 中，资源是通过 URL 进行识别和定位的。
对资源的操作，是通过 HTTP 方法来定义的。
HTTP 方法一样平常会映射到数据层的 CRUD 动作：

数据层动作

HTTP 方法

描述

Create

POST

新建资源

Read

GET

获取资源

Update

PUT 或 PATCH

更新资源

Delete

DELETE

删除资源

此映射不是严格限定，读者朋友可以根据实际情形灵巧映射。

比如很多网站会掩护用户的个人资料信息，如果用 REST 来设计干系操作的 API，可以这么设计：

操作项

URL

HTTP 方法

新增个人资料

http://api.example.com/profile

POST

查询个人资料

http://api.example.com/profile

GET

修正个人资料

http://api.example.com/profile

PUT

删除个人资料

http://api.example.com/profile

DELETE

大略讲，REST 便是 URL 定位资源，HTTP 方法操作资源。

REST 的涌现是对过去编程模式的重大颠覆，除了架构上客户端做事的解耦，前后端各司其职，也极大提升了开拓团队的研发效率。
希望我在编程模式上的变革和思考能对你有所启示。

以给我点个赞，分享给身边朋友，非常感谢读者朋友，也欢迎关注我，我会分享更多优质原创内容。