前后端分离优缺点
为什么要前后端分离
- pc,app,pad多端适应(一套接口-后台)
- 前后端开发职责不清
- 开发效率问题,前后端互相等待
- 后台开发语言和模板高度耦合,导致开发语言以来严重
缺点:
- 前后端学习门槛增加
- 数据依赖导致文档重要性增加
- 前端工作量加大
初识和简介
restful api介绍
目前前后端分离最佳时间(标准/规范-不是框架)
- 轻量,直接通过http,不需要额外的协议,post/get/put/delete操作
- 面向资源,一目了然,具有自解释性
- 资源的地址 在web中就是URL (统一资源标识符)
- 资源是REST系统的核心概念。 所有的设计都是以资源为中心
- 首先,restful是一种软件架构风格、设计风格,而不是标准,只是提供了一组设计原则和约束条件。满足这些约束条件和原则的应用程序或设计就是 RESTful。
- REST:Representational state transfer 表述性状态转移 其实就是对 资源 的表述性状态转移。
- REST提倡在URL中只出现名词,而对于名词的操作,则用不同的请求方式来区分不同类型的操作
规范和约束有哪些
- 每个资源都拥有一个资源标识,每个资源的资源标识可以用来唯一地标明该资源
- 消息的自描述性
- 资源的自描述性。
- HATEOAS Hypermedia As The Engine Of Application State(超媒体作为应用状态引擎)
- 即客户只可以通过服务端所返回各结果中所包含的信息来得到下一步操作所需要的信息,如到底是向哪个URL发送请求等。也就是说,一个典型的REST服务不需要额外的文档标示通过哪些URL访问特定类型的资源,而是通过服务端返回的响应来标示到底能在该资源上执行什么样的操作
核心思想:
用URL定位资源,用HTTP动词(GET,POST,DELETE,DETC)描述操作
这么约束的目的和好处:
- 实现客户端无需借助任何文档即能调用到所有的服务器资源
- 前后端分离。前端拿到数据只负责展示和渲染,不对数据做任何处理。后端处理数据并以JSON格式传输出去
- 定义这样一套统一的接口,在web,ios,android,PC三端都可以用相同的接口
- 在前后端分离的应用模式中 ,前端与后端的耦合度相对较低。
REST综述:
- 通过url标识定位资源的位置
- 通过请求方式区分对资源的操作
- 用HTTP Status Code传递Server的状态信息。
- 在前后端分离的应用模式中,我们通常将后端开发的每个视图都称为一个接口,或者API,前端通过访问接口来对数据进行增删改查。
Http状态码
2开头 (请求成功)表示成功处理了请求的状态代码。
- 200 (成功) 服务器已成功处理了请求。 通常,这表示服务器提供了请求的网页。
- 201 (已创建) 请求成功并且服务器创建了新的资源。
- 202 (已接受) 服务器已接受请求,但尚未处理。
- 203 (非授权信息) 服务器已成功处理了请求,但返回的信息可能来自另一来源。
- 204 (无内容) 服务器成功处理了请求,但没有返回任何内容。
- 205 (重置内容) 服务器成功处理了请求,但没有返回任何内容。
- 206 (部分内容) 服务器成功处理了部分 GET 请求。
3开头 (请求被重定向)表示要完成请求,需要进一步操作。 通常,这些状态代码用来重定向。
- 300 (多种选择) 针对请求,服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作,或提供操作列表供请求者选择。
- 301 (永久移动) 请求的网页已永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置。
- 302 (临时移动) 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。
- 303 (查看其他位置) 请求者应当对不同的位置使用单独的 GET 请求来检索响应时,服务器返回此代码。
- 304 (未修改) 自从上次请求后,请求的网页未修改过。 服务器返回此响应时,不会返回网页内容。
- 305 (使用代理) 请求者只能使用代理访问请求的网页。 如果服务器返回此响应,还表示请求者应使用代理。
- 307 (临时重定向) 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。
4开头 (请求错误)这些状态代码表示请求可能出错,妨碍了服务器的处理。
- 400 (错误请求) 服务器不理解请求的语法。
- 401 (未授权) 请求要求身份验证。 对于需要登录的网页,服务器可能返回此响应。
- 403 (禁止) 服务器拒绝请求。
- 404 (未找到) 服务器找不到请求的网页。
- 405 (方法禁用) 禁用请求中指定的方法。
- 406 (不接受) 无法使用请求的内容特性响应请求的网页。
- 407 (需要代理授权) 此状态代码与 401(未授权)类似,但指定请求者应当授权使用代理。
- 408 (请求超时) 服务器等候请求时发生超时。
- 409 (冲突) 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
- 410 (已删除) 如果请求的资源已永久删除,服务器就会返回此响应。
- 411 (需要有效长度) 服务器不接受不含有效内容长度标头字段的请求。
- 412 (未满足前提条件) 服务器未满足请求者在请求中设置的其中一个前提条件。
- 413 (请求实体过大) 服务器无法处理请求,因为请求实体过大,超出服务器的处理能力。
- 414 (请求的 URI 过长) 请求的 URI(通常为网址)过长,服务器无法处理。
- 415 (不支持的媒体类型) 请求的格式不受请求页面的支持。
- 416 (请求范围不符合要求) 如果页面无法提供请求的范围,则服务器会返回此状态代码。
- 417 (未满足期望值) 服务器未满足"期望"请求标头字段的要求。
5开头(服务器错误)这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误,而不是请求出错。
- 500 (服务器内部错误) 服务器遇到错误,无法完成请求。
- 501 (尚未实施) 服务器不具备完成请求的功能。 例如,服务器无法识别请求方法时可能会返回此代码。
- 502 (错误网关) 服务器作为网关或代理,从上游服务器收到无效响应。
- 503 (服务不可用) 服务器目前无法使用(由于超载或停机维护)。 通常,这只是暂时状态。
- 504 (网关超时) 服务器作为网关或代理,但是没有及时从上游服务器收到请求。
- 505 (HTTP 版本不受支持) 服务器不支持请求中所用的 HTTP 协议版本。
Http 动词
对于资源的具体操作类型,由HTTP动词表示。
常用的HTTP动词有下面四个(括号里是对应的SQL命令)。
- GET(SELECT):从服务器取出资源(一项或多项)。
- POST(CREATE):在服务器新建一个资源。
- PUT(UPDATE):在服务器更新资源(客户端提供改变后的完整资源)。
- DELETE(DELETE):从服务器删除资源。
还有三个不常用的HTTP动词
- PATCH(UPDATE):在服务器更新(更新)资源(客户端提供改变的属性)。
- HEAD:获取资源的元数据。
- OPTIONS:获取信息,关于资源的哪些属性是客户端可以改变的。
Django restframework
背景及介绍
django restframework是基于django和restful协议开发的框架,遵循Django restframework规范编写,可以:
- 自动生成符合 RESTful 规范的 API
支持 OPTION、HEAD、POST、GET、PATCH、PUT、DELETE - 根据 Content-Type 来动态的返回数据类型(如 text、json)
生成 browserable 的交互页面(自动为 API 生成非常友好的浏览器页面) - 非常细粒度的权限管理(可以细粒度到 field 级别)
在开发REST API的视图中,虽然每个视图具体操作的数据不同,但增、删、改、查的实现流程基本套路化,所以这部分代码也是可以复用简化编写的:
- 增:校验请求数据 -> 执行反序列化过程 -> 保存数据库 -> 将保存的对象序列化并返回
- 删:判断要删除的数据是否存在 -> 执行数据库删除
- 改:判断要修改的数据是否存在 -> 校验请求的数据 -> 执行反序列化过程 -> 保存数据库 -> 将保存的对象序列化并返回
- 查:查询数据库 -> 将数据序列化并返回
Django REST framework可以帮助我们简化上述两部分的代码编写,大大提高REST API的开发速度。
工作机制:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gCFlYhZV-1572707617436)(3.png)]
Django restframework 特点
- url简洁
- 开发高效
- 接口清晰
- 提供了定义序列化器Serializer的方法,可以快速根据Django ORM 或者其他库自动序列化/反序列化
- 提供了丰富的类视图+MIXIN扩展类,简化视图的编写
- 多种身份认证和权限认证方式的支持
- 直观的API web界面
- 开发高效
- 接口清晰
- 提供了定义序列化器Serializer的方法,可以快速根据Django ORM 或者其他库自动序列化/反序列化
- 提供了丰富的类视图+MIXIN扩展类,简化视图的编写
- 多种身份认证和权限认证方式的支持
- 直观的API web界面