REST架构

什么是REST架构

详细的解释在网上大家都能搜到，我就不多说了

通俗的来说，REST是一种组织软件的风格，而不是规范，它不强制你必须使用什么样的格式，只是建议你使用什么样的格式

它提出了一系列的想法，按照这些想法来组织软件，按照这些想法来请求资源

REST提出的想法都可以通过现有技术的合理运用，没有提出新的技术

它提供了关于API格式的想法，也就是我们所说的RESTfulAPI

这些想法、这种风格，叫做REST，下面就是它具体提出了哪些想法

大家可以在看完全部之后再回过头来看这一段，就会有更深刻的理解

版本号

REST提出了关于版本的想法

假设我们的软件新版本修改了一个函数，需要最新的客户端支持，旧版本的无法运行

但是我们都知道，新版本发布时大部分人不会更新，就会导致这样的问题：
新旧版本客户端都调用这个函数，但是这个函数被改过，而且新旧客户端使用的都是同一个API请求资源，所以旧版本的客户端不能用了

REST建议我们将函数最近的各个版本都留下来，给函数的每个版本赋予版本号，请求时带上版本号就可以了

此时API就变成了这样：

【GET】  /v1/users/{user_id}  // 版本 v1 的查询用户列表的 API 接口
【GET】  /v2/users/{user_id}  // 版本 v2 的查询用户列表的 API 接口

这样新旧版本就都可以使用，我们需要同时维护函数的几个版本，不必太多，只维护最近的几个函数版本即可，废弃很少有人用的版本，并强制使用那些版本的用户升级

资源路径

RESTful API对于资源路径提出以下观点：

• RESTful API 是以“资源”为核心的，每一个URL代表的都是“资源”，所以URL应该只有名词，可以有形容词，但是尽量少用
• 无论资源是一个还是多个，名词都使用复数
• 使用小写字母
• 数字及下划线来区分多个单词
  例如：

  【GET】  /v1/students/{student_id} 
  

  【POST】  /v1/schools/{school_id}/students/{student_id} // 添加学校的学生，这个大家看到可能会有些莫名的疑惑，后面我们会说明POST这一方式
  

• 资源变化难以使用纯名词或形容词来命名时，可以考虑使用一些特殊的 actions 命名

  /{resources}/{resource_id}/actions/{action}
  

  例如密码修改：

  【PUT】  /v1/users/{user_id}/password/actions/modify // 密码修改
  

请求方式

REST认为，对于不同种类的操作，请求时要使用不同的请求方式

请求方式	使用
GET	用于查询资源
POST	用于创建新的资源
PUT	用于更新服务端的资源的全部信息
PATCH	用于更新服务端的资源的部分信息
DELETE	用于删除服务端的资源。

比如

【GET】		/students/{student_id}		获取学生信息
【GET】		/students					获取所有学生列表
【POST】		/students					添加新学生
【PUT】		/students/{student_id}		修改该同学的所有信息
【PATCH】	/students/{student_id}	    修改该同学的部分信息
【DELETE】	/students/{student_id}		删除该同学

我们很少能看到除了【GET】和【POST】的其他请求方式，是因为并不是所有浏览器都支持这些请求方式，但是所有浏览器都支持【GET】【POST】

查询参数

何时使用查询参数 何时使用路径参数

• 分页查询
  • offset 指定返回记录