找人做一下网站大概多少钱,一个网站如何做双语,龙岗公司网站建设,外贸网站平台是不是很难做RestFul API
何为 API#xff1f;
API#xff08;Application Programming Interface#xff09; 翻译过来是应用程序编程接口的意思。
我们在进行后端开发的时候#xff0c;主要的工作就是为前端或者其他后端服务提供 API 比如查询用户数据的 API 。 但是#xff0c; …RestFul API
何为 API
APIApplication Programming Interface 翻译过来是应用程序编程接口的意思。
我们在进行后端开发的时候主要的工作就是为前端或者其他后端服务提供 API 比如查询用户数据的 API 。 但是 API 不仅仅代表后端系统暴露的接口像框架中提供的方法也属于 API 的范畴。
你可以把 API 理解为程序与程序之间通信的桥梁其本质就是一个函数而已。另外API 的使用也不是没有章法的它的规则由比如数据输入和输出的格式API 提供方制定。
何为 RESTful API
RESTful API 经常也被叫做 REST API它是基于 REST 构建的 API。这个 REST 到底是什么我们后文在讲涉及到的概念比较多。
如果你看 RESTful API 相关的文章的话一般都比较晦涩难懂主要是因为 REST 涉及到的一些概念比较难以理解。但是实际上我们平时开发用到的 RESTful API 的知识非常简单也很容易概括
举个例子如果我给你下面两个 API 你是不是立马能知道它们是干什么用的这就是 RESTful API 的强大之处
GET /classes列出所有班级
POST /classes新建一个班级RESTful API 可以让你看到 URLHttp Method 就知道这个 URL 是干什么的让你看到了 HTTP 状态码status code就知道请求结果如何。
像咱们在开发过程中设计 API 的时候也应该至少要满足 RESTful API 的最基本的要求比如接口中尽量使用名词使用 POST 请求创建资源DELETE 请求删除资源等等示例GET /notes/id获取某个指定 id 的笔记的信息。
解读 REST
REST 是 REpresentational State Transfer 的缩写。这个词组的翻译过来就是“表现层状态转化”。
这样理解起来甚是晦涩实际上 REST 的全称是 Resource Representational State Transfer 直白地翻译过来就是 “资源”在网络传输中以某种“表现形式”进行“状态转移” 。如果还是不能继续理解请继续往下看相信下面的讲解一定能让你理解到底啥是 REST 。
我们分别对上面涉及到的概念进行解读以便加深理解实际上你不需要搞懂下面这些概念也能看懂我下一部分要介绍到的内容。不过为了更好地能跟别人扯扯 “RESTful API”我建议你还是要好好理解一下 资源Resource我们可以把真实的对象数据称为资源。一个资源既可以是一个集合也可以是单个个体。比如我们的班级 classes 是代表一个集合形式的资源而特定的 class 代表单个个体资源。每一种资源都有特定的 URI统一资源标识符与之对应如果我们需要获取这个资源访问这个 URI 就可以了比如获取特定的班级/class/12。另外资源也可以包含子资源比如 /classes/classId/teachers列出某个指定班级的所有老师的信息 表现形式Representational“资源是一种信息实体它可以有多种外在表现形式。我们把资源具体呈现出来的形式比如 jsonxmlimage,txt 等等叫做它的表现层/表现形式”。 状态转移State Transfer大家第一眼看到这个词语一定会很懵逼内心 BB这尼玛是啥啊 大白话来说 REST 中的状态转移更多地描述的服务器端资源的状态比如你通过增删改查通过 HTTP 动词实现引起资源状态的改变。ps:互联网通信协议 HTTP 协议是一个无状态协议所有的资源状态都保存在服务器端。
综合上面的解释我们总结一下什么是 RESTful 架构
每一个 URI 代表一种资源客户端和服务器之间传递这种资源的某种表现形式比如 jsonxmlimage,txt 等等客户端通过特定的 HTTP 动词对服务器端资源进行操作实现表现层状态转化。
RESTful API 规范
动作
GET请求从服务器获取特定资源。举个例子GET /classes获取所有班级POST在服务器上创建一个新的资源。举个例子POST /classes创建班级PUT更新服务器上的资源客户端提供更新后的整个资源。举个例子PUT /classes/12更新编号为 12 的班级DELETE从服务器删除特定的资源。举个例子DELETE /classes/12删除编号为 12 的班级PATCH更新服务器上的资源客户端提供更改的属性可以看做作是部分更新使用的比较少这里就不举例子了。
路径接口命名
路径又称终点endpoint表示 API 的具体网址。实际开发中常见的规范如下 网址中不能有动词只能有名词API 中的名词也应该使用复数。 因为 REST 中的资源往往和数据库中的表对应而数据库中的表都是同种记录的集合collection。如果 API 调用并不涉及资源如计算翻译等操作的话可以用动词。比如GET /calculate?param111param233 。 不用大写字母建议用中杠 - 不用下杠 _ 。比如邀请码写成 invitation-code而不是 invitation_code 。 善用版本化 API。当我们的 API 发生了重大改变而不兼容前期版本的时候我们可以通过 URL 来实现版本化比如 http://api.example.com/v1、http://apiv1.example.com 。版本不必非要是数字只是数字用的最多日期、季节都可以作为版本标识符项目团队达成共识就可。 接口尽量使用名词避免使用动词。 RESTful API 操作HTTP Method的是资源名词而不是动作动词。
来举个实际的例子来说明一下吧现在有这样一个 API 提供班级class的信息还包括班级中的学生和教师的信息则它的路径应该设计成下面这样。
GET /classes列出所有班级
POST /classes新建一个班级
GET /classes/{classId}获取某个指定班级的信息
PUT /classes/{classId}更新某个指定班级的信息一般倾向整体更新
PATCH /classes/{classId}更新某个指定班级的信息一般倾向部分更新
DELETE /classes/{classId}删除某个班级
GET /classes/{classId}/teachers列出某个指定班级的所有老师的信息
GET /classes/{classId}/students列出某个指定班级的所有学生的信息
DELETE /classes/{classId}/teachers/{ID}删除某个指定班级下的指定的老师的反例
/getAllclasses
/createNewclass
/deleteAllActiveclasses理清资源的层次结构比如业务针对的范围是学校那么学校会是一级资源:/schools老师: /schools/teachers学生: /schools/students 就是二级资源。
过滤信息Filtering
如果我们在查询的时候需要添加特定条件的话建议使用 url 参数的形式。比如我们要查询 state 状态为 active 并且 name 为 guidegege 的班级
GET /classes?stateactivenameguidegege比如我们要实现分页查询
GET /classes?page1size10 //指定第1页每页10个数据状态码Status Codes
状态码范围
2xx成功3xx重定向4xx客户端错误5xx服务器错误200 成功301 永久重定向400 错误请求500 服务器错误201 创建304 资源未修改401 未授权502 网关错误403 禁止访问504 网关超时404 未找到405 请求方法不对
RESTful 的极致 HATEOAS RESTful 的极致是 hateoas 但是这个基本不会在实际项目中用到。 上面是 RESTful API 最基本的东西也是我们平时开发过程中最容易实践到的。实际上RESTful API 最好做到 Hypermedia即返回结果中提供链接连向其他 API 方法使得用户不查文档也知道下一步应该做什么。
比如当用户向 api.example.com 的根目录发出请求会得到这样一个返回结果
{link: {rel: collection https://www.example.com/classes,href: https://api.example.com/classes,title: List of classes,type: application/vnd.yourformatjson
}}上面代码表示文档中有一个 link 属性用户读取这个属性就知道下一步该调用什么 API 了。rel 表示这个 API 与当前网址的关系collection 关系并给出该 collection 的网址href 表示 API 的路径title 表示 API 的标题type 表示返回类型 Hypermedia API 的设计被称为HATEOASopen in new window。
在 Spring 中有一个叫做 HATEOAS 的 API 库通过它我们可以更轻松的创建出符合 HATEOAS 设计的 API。
作者声明
如有问题欢迎指正
