JavaScript 网络编程(一)
前后端的开发模式
前后端不分离的开发模式
在我们的早期的开发模式中,实现的是前后端不分离的开发模式,前后端不分离的时候,这个时候实现使用的是我们的
- 服务端渲染来实现渲染的前端页面(SSR server side render)
- 具体的实现就是我们的客户端向服务端发送请求,服务端返回对应的 HTML 文档
- 在这个过程中,我们客户端进行刷新页面的时候,客户端加载新的 HTML 文档
- 下面的就是我们的客户端的刷新页面的按钮
- 这种开发模式就是以我们的 Python 的web 开发框架 Django 为例子:该框架就是实现的是前后端不分离的开发模式
前后端不分离的开发模式的缺点
对开发人员的技术要求性高:前端网页的开发,后端数据库的操作,前后端业务逻辑的编写
所以说这个时候,我们就出现了我们的前后端分离的开发模式
- 前端实现书写我们的网页,以及渲染从服务端请求回来的数据
- 后端实现的是就是考虑对数据库的操作,对数据的增删改查的操作
- 但是这样的开发模式也是有一定的不足,开发前期必须前后端商量好,否则前后端矛盾就会激化 😢 😢 😢
服务端渲染就是实现的是我们的客户端的渲染的架构主要是我们的后端进行渲染我们的前端客户端页面,这个就是服务端渲染
前后端分离的开发模式
这个时候,我们的前端页面中的数据全部都是从后端中进行请求回来的,这个时候,我们的前端的数据就是一个动态的数据了
- 这个时候,我们前端需要做的就是搭建网页的结构 HTMl
- 实现书写网页的 CSS 的内联样式表
- 书写我们的 JavaScript 的网络编程实现从服务端发送网络请求,将数据进行渲染页面
- 所以说后面我们学习的前端框架,都是含有一句话的,就是数据驱动视图的开发模式
- 前端发送网络请求的目标就是服务端的提供的 API 接口
这个时候我们的网页的组装的过程就是使用的是我们的客户端的渲染模式,这个就是我们的前后端分离的开发模式了
- 也就是前端做自己的,后端做自己的
- 前端进行开发的部分项目部署的时候,实现的是我们的部署在我们的静态服务器中的
- 后端的对数据库的操作的,提供给前端的获取数据的 API 接口,这个就是部署在数据服务器中的
前后端开发模式中的,进行前后端的沟通的工具含有
- ApiFox | ApiPost | Postman
- 就是下面的三个工具
两种开发模式的具体的体现
接触过爬虫的都是可以知道的是
- 我们爬取一个网页的数据的时候,首先实现确定的是我们的发送请求的接口,从而实现获取服务端响应的数据
- 这个时候就可以发现的是,我们有的时候,请求返回的是 HTML 文档,有的时候服务端返回给客户端的响应是
- JSON 数据,这个就是因为两种不同的开发模式导致的呐
- 后面的话,我们在网络请求方面常见有两个单词: request 请求 | response 响应
前端请求数据的方式含有
- 前端在实现我们的向服务端请求数据的时候,浏览器默认提供给我们的两套 API : XHR | Fetch
- 这种向后端进行发送请求从而获取数据,并且不让网页整个刷新的技术就是 AJAX(Asynchronous JavaScript and XML)
HTTP 协议
超文本传输协议(HyperText Transfer Protocol)
- 是一种分布式、协作式和超媒体信息系统的应用层的协议(计算机网络,一共四大层【具体的我忘记了,记不住一点】)
- HTTP 协议出现的最初的目的是实现我们的发布和接收 HTML 页面的方法
- 通过 HTTP 和 HTTPS 协议请求的资源由统一资源标识符(Uniform Resource Identifiers , URI)来标识的
HTTP 是我们客户端和服务端之间的请求和响应的标准
通过浏览器、爬虫或者其他工具,客户端向服务端发送一个 HTTP 请求到服务器上的指定端口(默认的是 80端口)
- 这个时候,我们的这个客户端就是我们的用户代理程序(user agent)
响应的服务器上存储着一些资源,比如说我们的 HTML 文件和image 图像
- 我们就把这个响应服务器称之为源服务器(origin server)
我们的一个网页中实现获取的资源是被存放在我们的 web 资源服务器上的,由浏览器或者其他客户端程序自动的发送HTTP
- 请求来获取,解析,显示的
HTTP 组成
HTTP 主要包含两个部分,一个就是请求(request) ,一个就是响应(response)
请求报文包括: 请求行 + 请求头 + 空白行 + 请求体
请求行
- 请求方式的信息
- 请求的 URL 信息
- HTTP 协议版本信息
请求头
- 向服务器发送请求需要携带的信息设置,这个是服务器进行响应的要求的数据
请求体
- 包含了我们需要向服务器提交的数据信息
响应报文:响应行 + 响应头 + 空白行 + 响应体
响应行
- HTTP 版本信息
- 响应状态码
- 响应状态码的描述信息
响应头
- 响应的时候携带的信息
响应体
- 服务器给客户端响应的数据
HTTP 版本
HTTP 0.9
- 发布时间是 1991
- 这个时候,我们客户端实现请求的方式只有 Get 请求
HTTP 1.0
- 发布时间是 1996
- 这个时候实现支持了我们的 POST 请求 + HEAD 请求
- 但是浏览器和服务器之间建立了 TCP 链接,请求完成后都是会断开这个 TCP 链接,每次的请求对性能的消耗增大了
HTTP 1.1
- 发布时间是 1997
- 增加了 PUT 和 DELETE 请求
- 这里采用的客户端和服务器之间的连接是我们的持久化的连接,也就是说我们的多次请求使用的是同一个 TCP 连接
Connection: keep-aliveHTTP 2.0
HTTP 3.0
HTTP 请求方式
GET 请求 —— GET 请求是用来实现的是我们的获取服务端的请求数据的一种请求
POST 请求 —— POST 请求,实现的是向我们的服务器提交数据的一种请求
HEAD 请求 —— 获取的是和 GET 请求相同的响应,但是是没有响应体返回的
- 常用于文件下载的时候,先实现获取我们文件的大小信息,然后决定是否下载文件
PUT 请求 —— 请求有效载荷(payload)替换目标资源的所有当前表示
DELETE 请求 —— 请求删除指定的资源
PATCH 请求 —— 用于实现的是对资源进行部分修改的请求
CONNECT 请求 —— 建立一个到目标服务器的通道,通常是在我们的代理服务器的时候使用
TRACE 请求 —— 沿着目标资源的路径执行一个消息环回测试
在我们的开发中使用得最多的发送请求的方式含有
- GET 请求
- POST 请求
偶尔使用的请求方式
- PUT 请求
- DELETE 请求
- PATCH 请求
HTTP Request Header(请求头)
请求头中的数据内容是我们客户端默认需要给服务器传递的一些数据信息
一般包含的数据含有
content-type 是本次请求携带的数据的类型设置
application/x-www-form-urlencoded表示的是数据被编码的格式设置application/json表示的是我们的传输的数据是一个 JSON 数据text/plain表示的是文本类型application/xml表示的是xml类型multiplart/foem-data表示上传的是文件charset字符编码格式content-length 文件的大小长度,该部分的内容是自动计算的
keep-alive 用来实现的是我们的保持长久性的 TCP 连接的属性设置:
connection: keep-alive
- HTTP 1.1 是默认开启的
accept-encoding 告知服务器,客户端支持的文件压缩格式是什么
accept 告知服务器,客户端可接受的文件格式类型,如果通吃的话,可以设置的是:
*/*user-agent 就是实现的是指代客户的代理,爬虫的时候不得不使用这个进行伪装自己是爬虫用户,此时就需要使用该字段
HTTP Response 响应状态码
该部分就是我们的 HTTP 状态码(HTTP Status Code),用来实现的是就是描述我们的响应是否成功的信息,实在是太多
记不住一点,记住下面的 几个
xx分类即可 😢 😢 😢
- 1xx
- 2xx 响应成功的标识
- 3xx 重定向的标识
- 4xx 客户端出错的标识 —— 404 NOT FOUND (懂的都懂!!!)
- 5xx 服务器出问题的标识
总结
我们在该部分讲解了我们的前端网络请求的前言准备知识,一个就是前后端的开发模式的总结,一个就是 HTTP 协议的讲解
这两个部分对于我们后续的继续使用网络请求库是具有一定的帮助以及对我们平时发送网络请求的安全性问题也是有所提高的