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月前
|
JSON 监控 API
掌握使用 requests 库发送各种 HTTP 请求和处理 API 响应
本课程全面讲解了使用 Python 的 requests 库进行 API 请求与响应处理,内容涵盖环境搭建、GET 与 POST 请求、参数传递、错误处理、请求头设置及实战项目开发。通过实例教学,学员可掌握基础到高级技巧,并完成天气查询应用等实际项目,适合初学者快速上手网络编程与 API 调用。
463 130
|
3月前
|
XML JSON API
识别这些API接口定义(http,https,api,RPC,webservice,Restful api ,OpenAPI)
本内容介绍了API相关的术语分类,包括传输协议(HTTP/HTTPS)、接口风格(RESTful、WebService、RPC)及开放程度(API、OpenAPI),帮助理解各类API的特点与应用场景。
|
2月前
|
人工智能 API 开发者
图文教程:阿里云百炼API-KEY获取方法,亲测全流程
本文详细介绍了如何获取阿里云百炼API-KEY,包含完整流程与截图指引。需先开通百炼平台及大模型服务,再通过控制台创建并复制API-KEY。目前平台提供千万tokens免费额度,适合开发者快速上手使用。
1978 5
|
3月前
|
缓存 监控 Linux
Linux系统清理缓存(buff/cache)的有效方法。
总结而言,在大多数情形下你不必担心Linux中buffer与cache占用过多内存在影响到其他程序运行;因为当程序请求更多内存在没有足够可用资源时,Linux会自行调整其占有量。只有当你明确知道当前环境与需求并希望立即回收这部分资源给即将运行重负载任务之前才考虑上述方法去主动干预。
1557 10
|
3月前
|
缓存 监控 Ubuntu
Ubuntu操作系统下清除系统缓存与无用文件的方法
通过上述步骤断行综合性地对Ubuntu进行优化与整洁可显著改善其性能表现及响应速度。然而,请注意在执行某些操作前确保充分了解其潜在影响;例如,在移除旧内核之前确认新内核稳定运行无问题;而对于关键配置更改则需确保备份好相关设置以便恢复原状态。
599 0
|
4月前
|
SQL 缓存 监控
SqlRest让SQL秒变Http API,还支持20+数据库(含国产数据库)
杭州奥零数据科技有限公司成立于2023年,专注于数据中台业务,维护开源项目AllData并提供商业版解决方案。AllData提供数据集成、存储、开发、治理及BI展示等一站式服务,支持AI大模型应用,助力企业高效利用数据价值。
|
5月前
|
JSON 编解码 API
Go语言网络编程:使用 net/http 构建 RESTful API
本章介绍如何使用 Go 语言的 `net/http` 标准库构建 RESTful API。内容涵盖 RESTful API 的基本概念及规范,包括 GET、POST、PUT 和 DELETE 方法的实现。通过定义用户数据结构和模拟数据库,逐步实现获取用户列表、创建用户、更新用户、删除用户的 HTTP 路由处理函数。同时提供辅助函数用于路径参数解析,并展示如何设置路由器启动服务。最后通过 curl 或 Postman 测试接口功能。章节总结了路由分发、JSON 编解码、方法区分、并发安全管理和路径参数解析等关键点,为更复杂需求推荐第三方框架如 Gin、Echo 和 Chi。
|
5月前
|
缓存 负载均衡 监控
微服务架构下的电商API接口设计:策略、方法与实战案例
本文探讨了微服务架构下的电商API接口设计,旨在打造高效、灵活与可扩展的电商系统。通过服务拆分(如商品、订单、支付等模块)和标准化设计(RESTful或GraphQL风格),确保接口一致性与易用性。同时,采用缓存策略、负载均衡及限流技术优化性能,并借助Prometheus等工具实现监控与日志管理。微服务架构的优势在于支持敏捷开发、高并发处理和独立部署,满足电商业务快速迭代需求。未来,电商API设计将向智能化与安全化方向发展。
397 102
|
5月前
HTTP协议探究:常用方法一网打尽
总的来说,HTTP协议的命令犹如一把钥匙,解锁了互联网世界的大门。它是规则,也是工具,了解了它,就等于掌握了互联网的一把通行证。我们每天都在用,也常常无视它,但是只有深刻理解了它,才能更好地运用它。如此,我们的互联网世界旅程就会变得更加顺畅,更加有趣。
178 14
|
7月前
|
缓存 安全 Java
深入解析HTTP请求方法:Spring Boot实战与最佳实践
这篇博客结合了HTTP规范、Spring Boot实现和实际工程经验,通过代码示例、对比表格和架构图等方式,系统性地讲解了不同HTTP方法的应用场景和最佳实践。
749 5