http【详解】状态码,方法,接口设计 —— RestfuI API,头部 —— headers,缓存

简介: http【详解】状态码,方法,接口设计 —— RestfuI API,头部 —— headers,缓存

http 状态码

  • 200 成功

3xx 重定向(目标服务器返回另一个服务器的地址,浏览器会自动去访问另一个服务器)

301 永久重定向 (常用于已停服的旧域名/旧网址)


目标服务器返回301,并在返回信息的 headers 的 location 的值为新服务器地址,浏览器会转向请求新服务器,之后所有的请求都将不再访问原目标服务器,而是直接访问新服务器


302 临时重定向(配合 location,浏览器自动处理 )


目标服务器返回302,并在返回信息的 headers 的 location 的值为新服务器地址,浏览器会转向请求新服务器,但下次请求时,还是会访问原目标服务器


304 资源未被修改


当客户端缓存的资源(如css,js等)和服务器上的资源相同时,目标服务器会返回 304 ,并不再返回请求的资源。


4xx 客户端错误


403 没有权限

404 资源未找到

5xx 服务端错误


500 服务器错误

504 网关超时

http 方法

get 获取数据

post 新建数据

patch/put 更新数据

delete 删除数据

面试题:get 请求和 post 请求的区别

- 功能不同:get 用于从服务器获取数据,post 用于向服务器传递数据
- 传参方式不同:get 通过拼接url传递参数,会暴露在地址栏中,post 通过请求体(request body)传输参数,对用户不可见,相对于get 更安全。
- 传参数据大小限制不同:根据浏览器的不同,get 传输数据大小不能超过2k-4k,post 无限制,可传输大数据。
- 请求方式不同:
  
  get请求:
  1)浏览器请求tcp连接(第一次握手)
  2)服务器答应进行tcp连接(第二次握手)
  3)浏览器确认,并发送get请求头和数据(第三次握手)
  4)服务器返回200 OK响应

  psot请求:
  1)浏览器请求tcp连接(第一次握手)
  2)服务器答应进行tcp连接(第二次握手)
  3)浏览器确认并发送psot请求头(第三次握手)
  4)服务器返回100 Continue响应
  5)浏览器发送数据
  6)服务器返回200 OK响应

http 接口设计 —— RestfuI API

  • 传统 API设计: 把每个 url 当做一个功能
  • Restfu API设计: 把每个 url 当做一个唯一的资源

特点一:不使用 url 参数

传统 API设计 —— 随 url 参数的不同,执行不同的功能

/api/list?pageIndex=2

Restfu API设计 —— 每个 url 对应唯一的资源

/api/list/2

特点二:用 method 表示操作类型

传统 API设计 —— 根据请求方法无法判断出具体功能

// 创建数据  ————  post 请求
/api/create-blog

// 修改数据  ————  post 请求
/api/update-blog?id=100

// 查询数据  ————  get 请求
/api/get-blog?id=100

Restfu API设计 —— 每种请求方法对应固定的数据操作

// 创建数据  ———— post 请求
/api/blog

// 修改数据  ————  patch 请求 
/api/blog/100

// 查询数据  ————  get 请求
/api/blog/100

http 头部 —— headers

请求头 Request Headers

Accept 浏览器可接收的数据格式

Accept-Encoding 浏览器可接收的压缩算法,如 gzip,为减小流量消耗,服务端可能对数据进行了压缩再返回给客户端,客户端再解压使用。

Accept-Languange 浏览器可接收的语言,如 zh-CN

Connection: keep-alive 一次 TCP 连接重复使用(不用断开后再重新连接,提升了效率)

cookie 浏览器为识别用户身份缓存的信息,同域请求时,浏览器都会自动带上

Host 域名

【重要】User-Agent (简称 UA)浏览器信息,可用于对用户进行分析,如用户中使用谷歌浏览器的占比等。

Content-type 发送数据的格式,如 application/json,在 get 请求中没有这个参数。

If-Modified-Since 上次服务器返回的 Last-Modified 值(资源的最后修改时间),具体用途详见下文的协商缓存方案一 Last-Modified

If-None-Match 上次服务器返回的 Etag 值(资源的唯一标识符),具体用途详见下文的协商缓存方案二 Etag

返回头 Response Headers

  • Content-type 返回数据的格式,如application/json
  • Content-length 返回数据的大小,多少字节
  • Content-Encoding 返回数据的压缩算法,如 gzip
  • Set-Cookie 【重要】服务端可通过此参数,修改客户端浏览器中的cookie 信息
  • Cache-Control 控制强制缓存的逻辑
  • 【重要】max-age 缓存过期时间
  • 【重要】no-cache 禁止浏览器缓存
  • no-store 既禁止浏览器缓存,也禁止服务端缓存
  • private 只允许最终的客户端进行缓存
  • public 允许中间代理做缓存
Cache-Control: max-age=31536000 // 单位是秒
  • Expires 【了解即可】与 Cache-Control 功能相同,已被其代替。
  • Last-Modified 资源的最后修改时间,具体用途详见下文的协商缓存方案一 Last-Modified
  • Etag 能唯一标识资源的字符串 ,具体用途详见下文的协商缓存方案二 Etag

自定义 Headers

使用场景:限定客户端必须带有指定的 Headers 信息才能访问服务器,否则视为非法访问

// axios 中自定义 Headers 的方法
headers:{'自定义的请求头key':'自定义的请求头的值'}

缓存相关的 headers

http 缓存

客户端浏览器将从目标服务器请求到的数据,在浏览器的本地中存储一份,以便下次请求时,不再重新请求相关数据。

http 缓存的意义(为什么要有http 缓存)

可以减少http请求的数量和体积,从而提升性能(让页面渲染更快,缓解了服务器压力,减少了不必要的数据传输【节省了带宽】)

哪些资源可以被缓存?

静态资源( js,css,img )

强制缓存

  • 第一次请求时,服务器会返回相应的资源,若返回头中带有 Cache-Control 则该资源会被浏览器缓存
  • 后续请求时,会先判断访问时间是否超过了 Cache-Control 限定的有效期,若没有超过有效期,则会使用本地缓存中的数据,不会访问服务器。

  • 若超过有效期,则会再次访问服务器获取资源

协商缓存

  • 是服务器端的一种缓存策略
  • 由服务器判断客户端资源是否和服务端资源一样
  • 一样则返回 304,不一样则返回 200 和最新的资源

方案一 Last-Modified 资源的最后修改时间

  • 第一次请求时,服务器返回资源和 Last-Modified
  • 后续请求,在请求头中会带上 If-Modified-Since (值为上次服务器返回的 Last-Modified 值)
  • 服务器将对比请求头中的 If-Modified-Since 值和服务器上资源的最后修改时间
  • 若客户端传来的资源最后修改时间与服务器上资源的最后修改时间相同,则说明资源没有发生变化,服务器返回 304
  • 若客户端传来的资源最后修改时间与服务器上资源的最后修改时间不同,则说明资源有更新,服务器返回新的资源和新的 Last-Modified

方案二 Etag 资源的唯一标识符

原理与Last-Modified相同,只是Last-Modified的值是时间,Etag是一个能唯一标识资源的字符串

  • 第一次请求时,服务器返回资源和 Etag
  • 后续请求,在请求头中会带上 If-None-Match (值为上次服务器返回的 Etag 值)
  • 服务器将对比请求头中的 If-None-Match 值和服务器上资源的 Etag 值
  • 若客户端传来的资源唯一标识符与服务器上资源的唯一标识符相同,则说明资源没有发生变化,服务器返回 304
  • 若客户端传来的资源唯一标识符与服务器上资源的唯一标识符不同,则说明资源有更新,服务器返回新的资源和新的 Etag

两种方案可以同时使用

同时使用 Last-Modified 和 Etag 时,会优先使用 Etag ,因为 Last-Modified 只能精准到秒,且如果资源被重复生成,内容不变时,Etag 更精确。(资源重复生成,但内容不变时,Etag 也不会变)

(学习要求:上图需能无任何提示自行绘制出来!)

刷新操作对缓存的影响

页面跳转刷新 – 强制缓存有效,协商缓存有效

如地址栏输入 ur,跳转链接,前进后退等

手动刷新 – 强制缓存失效,协商缓存有效

windows 快捷键 F5,点击刷新按钮,右击菜单刷新

强制刷新 – 强制缓存失效,协商缓存失效

windows 快捷键 ctrl +F5

目录
相关文章
|
2月前
|
SQL 缓存 开发框架
分享一个 .NET EF6 应用二级缓存提高性能的方法
分享一个 .NET EF6 应用二级缓存提高性能的方法
|
5天前
|
存储 缓存 NoSQL
解决Redis缓存击穿问题的技术方法
解决Redis缓存击穿问题的技术方法
19 2
|
5天前
|
缓存 NoSQL Redis
解决 Redis 缓存穿透问题的有效方法
解决 Redis 缓存穿透问题的有效方法
17 2
|
2月前
|
运维 Serverless 调度
函数计算产品使用问题之怎么在HTTP触发的函数里添加或读取自定义头部
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
2月前
|
缓存 监控 NoSQL
【Azure Redis 缓存】Redis的监控方式? 是否有API接口调用来获取监控值
【Azure Redis 缓存】Redis的监控方式? 是否有API接口调用来获取监控值
|
2月前
|
Oracle Java 关系型数据库
JDK版本特性问题之在 JDK 11 中,HTTP Client API 的特点有哪些
JDK版本特性问题之在 JDK 11 中,HTTP Client API 的特点有哪些
|
3月前
|
消息中间件 API 数据库
在微服务架构中,每个服务通常都是一个独立运行、独立部署、独立扩展的组件,它们之间通过轻量级的通信机制(如HTTP/RESTful API、gRPC等)进行通信。
在微服务架构中,每个服务通常都是一个独立运行、独立部署、独立扩展的组件,它们之间通过轻量级的通信机制(如HTTP/RESTful API、gRPC等)进行通信。
|
3月前
|
监控 Sentinel 缓存
高并发架构设计三大利器:缓存、限流和降级问题之RateLimiter的acquire()方法有什么作用
高并发架构设计三大利器:缓存、限流和降级问题之RateLimiter的acquire()方法有什么作用
|
21天前
|
canal 缓存 NoSQL
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
根据对一致性的要求程度,提出多种解决方案:同步删除、同步删除+可靠消息、延时双删、异步监听+可靠消息、多重保障方案
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
|
2月前
|
缓存 NoSQL Java
Redis深度解析:解锁高性能缓存的终极武器,让你的应用飞起来
【8月更文挑战第29天】本文从基本概念入手,通过实战示例、原理解析和高级使用技巧,全面讲解Redis这一高性能键值对数据库。Redis基于内存存储,支持多种数据结构,如字符串、列表和哈希表等,常用于数据库、缓存及消息队列。文中详细介绍了如何在Spring Boot项目中集成Redis,并展示了其工作原理、缓存实现方法及高级特性,如事务、发布/订阅、Lua脚本和集群等,帮助读者从入门到精通Redis,大幅提升应用性能与可扩展性。
60 0
下一篇
无影云桌面