REST与RESTFul API最佳实践

我常常会面试一些作PHP的开发者，让我很奇怪的是，10我的总有8个多不知道什么是REST服务，甚至是没有据说过。但RESTFul API已是如今互联网里对外开放接口的主流模式，可参考：

豆瓣API https://developers.douban.com/wiki/?title=api_v2

GitHub https://developer.github.com/v3/

数一数年限，据我接触REST到如今也差很少有8年左右了。可能你们如今对从JavaScript客户端直接访问服务器API这种模式很是的习觉得常，但在8年前，Web并非如今这个样子的。要说REST，咱们先来看看在REST流行以前Web客户端是如何访问服务器接口的。

早期在移动端没有流行以前，Web API的概念还很是的弱，当时是网站盛行的年代，基本遵循着后台-前端的模型。后台产生数据，而后经过“模板”的形式将数据绑定到前端HTML代码里（渲染）。以下图所示：

那么这里就有一个“域”的概念，JavaScript只能访问同一个域的服务器。好比咱们将一个站点部署在A这个域名www.a.com下，那么这个站点的前端JavaScript只能访问域名为www.a.com的服务端。若是咱们须要访问非A站点的其余“服务”怎么办？看看下图：

在当时通用的作法是使用SOAP，Simple Object Access Protocol，简单对象协议，它使用XML做为数据的描述。咱们看看使用SOAP的解决方案：

JavaScript是不能直接访问SOAP服务的，须要首先访问本身的网站后台，再有网站后台访问SOAP服务。并且不一样语言的网站后台，方位SOAP服务都须要有首先生成本身特定语言的“代理类”，Java有Java的、C#有C#的，这至关的繁琐与很差理解。这个时候咱们的思考点来了，网站的后台对我来讲意义是什么？ 我为何不能直接访问服务？为何我不能把网站里的业务代码也提取成服务，最后变成如下的理想状况：

网站的后台几乎是个“壳子”，只负责网站自己的HTML页面、CSS、JavaScript文件等静态页面。而业务逻辑，交给服务来提供就行了。这样作的最大的好处是，业务变得独立了，能够被多个“网站”来共享访问了。有没有以为挺熟悉？这个模式就是如今VUE、AngularJS等框架作的单页面应用程序。可是，在当时这种模式并不流行。我在不少年前就尝试这样的思惟来构建Web，可是因为没有如今VUE、AngularJS等强大的SPA框架支持，效果并很差。但，我相信这种简洁的模式是Web的将来。我一贯崇尚简洁，当年丢掉Flex、Silverlight、ASP.Net WebForm，独独选择JavaScript就是由于其余几个封装太多。

不少人认为模板引擎就是很好的先后端分离，可我不这么认为，SPA才是真正的先后端分离，他们之间使用AJax通讯，前端就是最简单的HTML，前端开发人员一行服务器代码都看不到，这才是真的和语言无关，才是真正的先后端分离。

我来分析下，为何之前SPA应用并不流行。
第一，一个是网站的思惟根深蒂固；
第二，就是出于性能考虑，单页面频繁的Ajax请求将给服务器形成巨大的压力。而网站网页的静态化技术已是很是的成熟的了，因此SPA这个概念在早期并不怎么提倡。并且SPA也有本身的局限性，并非全部的网站都适合用SPA来代替。但如今服务器缓存技术的发展（特别是Memcache和Redis出现后）大大的解决了服务器支持SPA负载太高的问题，甚至比传统的网页静态化技术更加的简单易用；再加上VUE、AngularJS强大的能力，这才使SPA真正的流行起来。
第三，前端要跨域访问服务器在当时并非那么容易，没有一个标准的规范来定义跨域，各类旁门左道的跨域都不是那么的好用。

那么我我的认为有两个标致性的事物刷新了人们对于API和服务的理解：一个是移动端的流行，第二个就是REST理念的流行。
移动端咱们就不谈了。咱们来谈谈REST。我我的认为REST并非什么技术，而是因为它的流行，让人们逐渐的接受了服务即资源，扩展和打破了开发者对Web的理解。

没有REST的时候，客户端可不能够直接跨域访问服务？能够。但并无一个标准来引导开发者如何设计出适合服务的API接口。REST的流行，替代了SOAP（某些领域里SOAP仍是有一席之地），它足够简单、轻量、语义明确，很是适合移动端盛行的这个年代。

REST：REpresentational State Transfer，中译为“表属性状态传递”。这是什么鬼？这并不重要，原本就个名字就源自于国外的一个博士的一篇论文。咱们主要要知道基于这篇论文里的理论，衍生出了RESTFul API的接口设计风格。
咱们一块儿来看看RESTFul API有哪些特色：

1. 基于“资源”，数据也好、服务也好，在RESTFul设计里一切都是资源。
2. 无状态。一次调用通常就会返回结果，不存在相似于“打开链接-访问数据-关闭链接”这种依赖于上一次调用的状况。
3. URL中一般不出现动词，只有名词
4. URL语义清晰、明确
5. 使用HTTP的GET、POST、DELETE、PUT来表示对于资源的增删改查

6. 使用JSON不使用XML

   我举个例子：
   网站：/get_user?id=3
   RESTFul: GET /user/3 (GET是HTTP类型)

有些同窗可能会说，GET、POST我也常常用啊。可是在网站里的GET和POST同RESTFul中的GET、POST是不同的。网站里使用GET、POST的选择点在于，简单的用GET、复杂对象用POST；但在REST里，GET对应的是查询一个资源，而POST对应的是新增一个资源，意义是决然不一样的。理解这一点很是重要。

好，咱们接着来看一看RESTFul API的一些最佳实践原则：

1. 使用HTTP动词表示增删改查资源， GET：查询，POST：新增，PUT：更新，DELETE：删除
2. 返回结果必须使用JSON
3. HTTP状态码，在REST中都有特定的意义：200，201,202,204,400,401,403,500。好比401表示用户身份认证失败，403表示你验证身份经过了，但这个资源你不能操做。
4. 若是出现错误，返回一个错误码。好比我一般是这么定义的：

1. API必须有版本的概念，v1，v2，v3
2. 使用Token令牌来作用户身份的校验与权限分级，而不是Cookie。
3. url中大小写不敏感，不要出现大写字母
4. 使用 - 而不是使用 _ 作URL路径中字符串链接。
5. 有一份漂亮的文档~（很重要）

以上只是列出了RESTFul的部分实践原则，并不是所有。 给出一个典型的RESTFul API设计风格：

https://api.z.cn/v1/product/recent?page=3&size=20

以上URL很是容易理解，分页获取最新若干的Product资源。

最后，咱们想聊一下，RESTFul API到底好用吗？某些状况好用，某些状况很是很差用。什么状况好用，什么状况很差用呢？
个人一个经验性的总结：对于开放的API，豆瓣、新浪微博、GitHub，好用，很是合适；对于内部开发，很差用。
基于资源型的RESTFul API 接口粒度和返回结果过于的“粗”，它一般返回的都是完整的数据模型，这对于客户端很是不友好。但开放API之因此开放，就是由于它不知道你到底须要什么返回结果，既然不知道，那么我干脆都返回给你。这样的好处是通用，但客户端很差处理。你只须要一个字段，服务器啪的丢给你十几个，做为客户端开发者你怎么想？

内部开发因为需求很是明确，一般来讲服务器是不该该简单粗暴的直接甩资源实体给客户端的。那RESTFul API就不能接入到内部开发吗？固然不是，咱们须要灵活一些借鉴RESTFul中的优势，来设计咱们的内部API。那么如何简化，这就不是一篇文章可以说清楚的了，也没有一个统一的标准，须要本身去琢磨和体会。

最后举个例子吧，我我的在开发内部接口时会保留绝大多数的REST 特性，但我不会严格的只写增、删、改、查四个接口。必要的时候，仍是要灵活处理一下。并且错误码、状态码这些很是优秀的特性，必须保留。

好了，关于RESTFul咱们就介绍到这里。特别强调，接口设计是一个很是依赖于经验和重构的技术活儿，设计接口须要有一些艺术家的天赋（真实体会），你看GitHub的接口就很是的“美”。不要以为很简单，真的比写代码还难。难道你们不以为，有时候起名字真的是一件很难的事儿嘛？

本文原创发布于慕课网 ，转载请注明出处，谢谢合做！

做者： 7七月 
连接：http://www.imooc.com/article/17650
来源：慕课网
本文原创发布于慕课网 ，转载请注明出处，谢谢合做！

 

出处：https://blog.csdn.net/u013063153/article/details/72811976