前言
其实在学校听学长提过API，但是当时根本没有用过，也就是一个懵懵懂懂的概念，现在毕业出来找工作，包括现在工作中也问到有没有进行过API开发，感觉好像会但又说不清楚，现在就这个问题在网上好好学习一下，总结到这篇博文中。
REST
REST -- REpresentational State Transfer，翻译过来就是表现层状态转移，通俗一点讲是资源在网络中以某种表现形式进行状态转移，实际开发中就是用URL定位资源，用HTTP动词（GET、POST、PUT、DELETE）描述操作。
- Resource：资源，即数据；
- Representational：某种表现形式，比如JSON、XML、JPEG等；
- State Transfer：状态变化，通过HTTP动词实现
URL（统一资源标志符）：可以唯一标识一个资源
URL（统一资源定位符）：可以提供找到某个资源的路径
RESTful API
RESTful API就是REST风格的API，即REST是一种架构风格，采用HTTP做传输协议。
RESTful API 就可以通过一套统一的接口为所有客户端提供web服务，实现前后端分离。
这样做的好处：
- 实现前后端的解耦
- 可以将前段和后端部署到不同的服务器来减轻服务器压力
- 前后端代码在不同服务器上，可以提高安全性
设计原则和规范
- 资源：资源就是网上的一个实体，一段文本，一张图片或者一首歌曲。资源总是通过一种载体来反应它的内容。文本可以用TXT或者XML，图片可以使JPG或者PNG格式，JSON是现在最常见的资源表现实现。
- 统一接口：RESTful风格的数据元素操作CRUD（create,read,update,delete）分别对应HTTP方法：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源，这样就统一了数据操作的接口。
- URI：可以用一个URI（统一资源定位符）指向资源，即每个URI都对应一个特定的资源。要获取这个资源访问它的URI就可以，因此URI就成了每一个资源的地址或识别符。一般的，每个资源至少有一个URI与之对应，最典型的URI就是URL。
- 无状态：无状态是指所有的资源都可以URI定位，而且这个定位于其他资源无关，也不会因为其他资源的变化而变化，有状态和无状态的区别，举个例子说明一下，例如要查询员工工资的步骤为第一步：登录系统。第二步：进入查询工资的页面。第三步：搜索该员工。第四步：点击姓名查看工资。这样的操作流程就是有状态的，查询工资的每一个步骤都依赖于前一个步骤，只要前置操作不成功，后续操作就无法执行。如果输入一个URL就可以得到指定员工的工资，则这种情况就是无状态的，因为获取工资不依赖于其他资源或状态，且这种情况下，员工工资是一个资源，由一个URL与之对应可以通过HTTP中的GET方法得到资源，这就是典型的RESTful风格。
举例
-
GET:http://www.xxx.com/source/id 获取指定ID的某一类资源。
例如GET:http://www.xxx.com/friends/123 表示获取ID为123的会员的好友列表。如果不加id就表示获取所有会员的好友列表。 -
POST:http://www.xxx.com/friends/123 表示为指定ID为123的会员新增好友。
其他
- 应该将API的版本号放入URL。GET:http://www.xxx.com/v1/friend/123。 或者将版本号放在HTTP头信息中。要不要版本号取决于自己开发团队的习惯和业务的需要，不是强制的。
- URL中只能有名词而不能有动词，操作的表达是使用HTTP的动词GET,POST,PUT,DELETEL。URL只标识资源的地址，既然是资源那就是名词了。
- 如果记录数量很多，服务器不可能都将它们返回给用户。API应该提供参数，过滤返回结果。?limit=10：指定返回记录的数量、?page=2&per_page=100：指定第几页，以及每页的记录数。
原文参考：https://blog.csdn.net/hjc1984117/article/details/77334616