1. Web应用模式
在开发Web应用中,有两种应用模式: 1. 前后端不分离[客户端看到的内容和所有界面效果都是由服务端提供出来的。 [前后端不分离](assets/depended_frontend_backend.png) 2. 前后端分离【把前端的界面效果(html,css,js分离到另一个服务端或另一个目录下,python服务端只需要返回数据即可)】 前端形成一个独立的网站/独立的地址,服务端构成一个独立的网站 [前后端分离](assets/indepent_frontend_backend.png)
2. api接口
应用程序编程接口(Application Programming Interface,API接口),就是应用程序对外提供了一个操作数据的入口,这个入口可以是一个函数或类方法,也可以是一个url地址或者一个网络地址。当客户端调用这个入口,
应用程序则会执行对应代码操作,给客户端完成相对应的功能。 当然,api接口在工作中是比较常见的开发内容,有时候,我们会调用其他人编写的api接口,有时候,我们也需要提供api接口给其他人操作。由此就会带来一个问题,api接口往往都是一个函数、类方法、或者url或其他网络地址,
不断是哪一种,当api接口编写过程中,我们都要考虑一个问题就是这个接口应该怎么编写?接口怎么写的更加容易维护和清晰,这就需要大家在调用或者编写api接口的时候要有一个明确的编写规范!!! 为了在团队内部形成共识、防止个人习惯差异引起的混乱,我们都需要找到一种大家都觉得很好的接口实现规范,而且这种规范能够让后端写的接口,用途一目了然,减少客户端和服务端双方之间的合作成本。 目前市面上大部分公司开发人员使用的接口实现规范主要有:restful、RPC。
RPC( Remote Procedure Call )
RPC翻译成中文:远程过程调用[远程服务调用]. 从字面上理解就是访问/调用远程服务端提供的api接口。这种接口一般以服务或者过程式代码提供。
+ 服务端提供一个**唯一的访问入口地址**:http://api.xxx.com/ 或 http://www.xx.com/api 或者基于其他协议的地址 + 客户端请求服务端的时候,所有的操作都理解为**动作**(action),如果是web开发时,对应的就是HTTP请求的post请求 + 通过**请求体**参数,指定要调用的接口名称和接口所需的参数 action=get_all_student&class=301&sex=1 m=get_all_student&sex=1&age=22 command=100&sex=1&age=22 + 基本上现有rpc的数据格式:protobuf(gRPC)、json、xml
rpc接口多了,对应函数名和参数就多了,前端在请求api接口时难找.对于年代久远的rpc服务端的代码也容易出现重复的接口
restful
restful: 翻译成中文: 资源状态转换.(表征性状态转移) + 把服务端提供的所有的数据/文件都看成资源, 那么通过api接口请求数据的操作,本质上来说就是对资源的操作了. 因此,restful中要求,我们把当前接口对外提供哪种资源进行操作,就把**资源的名称写在url地址**。 /students/ /avatars/ + web开发中操作资源,最常见的最通用的无非就是增删查改,所以restful要求在地址栏中声明要操作的资源是什么。然后通过**http请求动词**来说明对该资源进行哪一种操作. POST http://www.xxx.com/api/students/ 添加学生数据 GET http://www.xxx.com/api/students/ 获取所有学生 DELETE http://www.xxx.com/api/students/<pk>/ 删除id=pk的一个学生 PUT http://www.xxx.com/api/students/<pk>/ 修改一个学生的全部信息 [id,name,sex,age,] PATCH http://www.xxx.com/api/students/<pk>/ 修改一个学生的部分信息[age] 也就是说,我们仅需要通过url地址上的资源名称结合HTTP请求动作,就可以说明当前api接口的功能是什么了。 restful是以**资源**为主的api接口规范,体现在地址上就是资源就是以名词表达。 rpc则以**动作**为主的api接口规范,体现在接口名称上往往附带操作数据的动作。
3. RESTful API规范
REST全称是Representational State Transfer,中文意思是表述(编者注:通常译为表征)性状态转移。 它首次出现在2000年Roy Fielding的博士论文中。 RESTful是一种专门为Web 开发而定义API接口的设计风格,尤其适用于前后端分离的应用模式中。 这种风格的理念认为后端开发任务就是提供数据的,对外提供的是数据资源的访问接口,所以在定义接口时,客户端访问的URL路径就表示这种要操作的数据资源。 而对于数据资源分别使用POST、DELETE、GET、UPDATE等请求动作来表达对数据的增删查改。 | GET | /students | 获取所有学生 | | -------- | -------------- | ------------------ | | 请求方法 | 请求地址 | 后端操作 | | POST | /students | 增加学生 | | GET | /students/<pk> | 获取编号为pk的学生 | | PUT | /students/<pk> | 修改编号为pk的学生 | | DELETE | /students/<pk> | 删除编号为pk的学生 |
restful规范是一种通用的规范,不限制语言和开发框架的使用。事实上,我们可以使用任何一门语言,任何一个框架都可以实现符合restful规范的API接口。
参考文档:http://www.runoob.com/w3cnote/restful-architecture.html
## 幂等性
## 幂等性 接口实现过程中,会存在**幂等性**。所谓幂等性是指代**客户端发起多次同样请求时,是否对于服务端里面的资源产生不同结果**。如果**多次请求**,服务端**结果**还是**一样**,则属于**幂等接口**,
如果多次请求,服务端产生结果是不一样的,则属于非幂等接口。 | 请求方式 | 是否幂等 | 是否安全 | | --------- | -------- | -------- | | GET | 幂等 | 安全 | | POST | 不幂等 | 不安全 | | PUT/PATCH | 幂等 | 不安全 | | DELETE | 幂等 | 不安全 |
标签:http,入门,students,restful,接口,api,快速,服务端,drf From: https://www.cnblogs.com/TodayWind/p/17067677.html