docs(note): 添加笔记目录及 gitignore 规则
- 新增 note 目录包含 AI、SQL、Golang、网络等多领域学习笔记 - 更新 .gitignore 添加 note/assets/ 和 note/项目/ 忽略规则
This commit is contained in:
张育新
@@ -0,0 +1,120 @@
|
||||
### URL设计规范
|
||||
|
||||
URL为统一资源定位器 ,接口属于服务端资源，通常一个完整的URL组成由以下几个部分构成：
|
||||
|
||||
```
|
||||
URI = scheme "://" host ":" port "/" path [ "?" query ][ "#" fragment ]
|
||||
```
|
||||
|
||||
- **scheme**: 指底层用的协议，如http、https、ftp
|
||||
- **host**: 服务器的IP地址或者域名
|
||||
- **port**: 端口，http默认为80端口
|
||||
- **path**: 访问资源的路径，就是各种web 框架中定义的route路由
|
||||
- **query**: 查询字符串，为发送给服务器的参数，在这里更多发送数据分页、排序等参数。
|
||||
- **fragment**: 锚点，定位到页面的资源
|
||||
|
||||
|
||||
|
||||
**通常一个RESTful API的path组成**如下：
|
||||
|
||||
```undefined
|
||||
/{version}/{resources}/{resource_id}
|
||||
```
|
||||
|
||||
- **version**：API版本号，有些版本号放置在头信息中也可以，通过控制版本号有利于应用迭代。
|
||||
- **resources**：资源，RESTful API推荐用小写英文单词的复数形式。
|
||||
- **resource_id**：资源的id，访问或操作该资源。
|
||||
|
||||
|
||||
|
||||
有时候可能资源级别较大，其下还可细分很多子资源也可以灵活设计URL的path，例如：
|
||||
|
||||
```undefined
|
||||
/{version}/{resources}/{resource_id}/{subresources}/{subresource_id}
|
||||
```
|
||||
|
||||
|
||||
|
||||
当增删改查无法满足业务要求，可以在URL末尾加上action，例如
|
||||
|
||||
```
|
||||
/{version}/{resources}/{resource_id}/action
|
||||
```
|
||||
|
||||
其中action就是对资源的操作。
|
||||
|
||||
|
||||
|
||||
**RESTful API的URL具体设计的规范**如下：
|
||||
|
||||
1. 不用大写字母，所有单词使用英文且小写。
|
||||
2. 连字符用中杠`"-"`而不用下杠`"_"`
|
||||
3. 正确使用 `"/"`表示层级关系,URL的层级不要过深，并且越靠前的层级应该相对越稳定
|
||||
4. 结尾不要包含正斜杠分隔符`"/"`
|
||||
5. URL中不出现动词，用请求方式表示动作
|
||||
6. 资源表示用复数不要用单数
|
||||
7. 不要使用文件扩展名
|
||||
|
||||
|
||||
|
||||
**[参考网址](https://www.cnblogs.com/bigsai/p/14099154.html)**
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
### HTTP方法
|
||||
|
||||
- **GET**
|
||||
|
||||
GET请求会向数据库发索取数据的请求，从而来获取资源，该请求就像数据库的select操作一样，**只是用来查询数据，不会影响资源的内容**。无论进行多少次操作，结果都是一样的
|
||||
|
||||
- **POST**
|
||||
|
||||
POST请求向服务器发送数据，但是该请求**会改变数据的内容(新添)**，就像数据库的`insert`操作一样，会创建新的内容，且POST请求的请求参数都是请求体中，其大小是没有限制的
|
||||
|
||||
- **PUT**
|
||||
|
||||
PUT请求是向服务器端发送数据的， 与POST请求不同的是，PUT请求**侧重于数据的修改 ,就像数据库中update一样**，而POST请求侧重于数据的增加
|
||||
|
||||
- **DELETE**
|
||||
|
||||
用来**删除资源**,和数据库中`delete`相对应
|
||||
|
||||
|
||||
|
||||
### 参数填写位置
|
||||
|
||||
- **Params（Query 参数）**：用于 GET 请求或其他将参数**附加在 URL 中**的情况。
|
||||
|
||||
- **Body（请求体）**：用于 POST、PUT 等请求方法，将参数**包含在请求体**中。
|
||||
|
||||
|
||||
|
||||
### 常见的请求文件类型及其适用场景
|
||||
|
||||
- **application/json**
|
||||
|
||||
用途：用于传输结构化数据，如对象和数组。
|
||||
|
||||
场景：客户端与服务器之间交换数据时，尤其是在前后端分离的应用中。
|
||||
|
||||
- **multipart/form-data**
|
||||
|
||||
用途：用于上传文件或包含文件的表单数据。
|
||||
|
||||
场景：用户上传图片、视频、文档等文件。
|
||||
|
||||
- **application/x-www-form-urlencoded**
|
||||
|
||||
用途：用于提交简单的表单数据。
|
||||
|
||||
场景：传统的表单提交，数据量较小且不包含文件。
|
||||
|
||||
- **application/octet-stream**
|
||||
|
||||
用途：用于传输二进制数据。
|
||||
|
||||
场景：下载文件或通过 API 提供文件流。
|
||||
@@ -0,0 +1,92 @@
|
||||
## Cookie
|
||||
|
||||
| 维度 | 说明 |
|
||||
| :----------- | :----------------------------------------------------------- |
|
||||
| **本质** | 存储在浏览器端的一小段文本数据（通常 4KB 以内） |
|
||||
| **核心机制** | 浏览器在每次 HTTP 请求中**自动携带**符合域名/路径规则的 Cookie |
|
||||
| **关键属性** | `HttpOnly`（防 JS 读取）、`Secure`（仅 HTTPS）、`SameSite`（防 CSRF）、`Expires/Max-Age` |
|
||||
| **定位** | **传输载体，而非认证方案本身**——它负责把令牌（Session ID 或 Token）在客户端和服务器之间来回搬运 |
|
||||
|
||||
**优点**：
|
||||
|
||||
- 简单成熟，几乎所有 Web 框架默认集成
|
||||
- 服务端可随时销毁会话，控制力强
|
||||
- 敏感信息存在服务端，不暴露给客户端
|
||||
|
||||
**缺点**：
|
||||
|
||||
- 扩展性受限——多服务器需共享 Session（引入 Redis 等外部存储）
|
||||
- 依赖 Cookie，纯移动端/非浏览器环境不友好
|
||||
- 容易受到 CSRF 攻击（需额外防护）
|
||||
|
||||
## Session
|
||||
|
||||
| 维度 | 说明 |
|
||||
| :----------- | :----------------------------------------------------------- |
|
||||
| **本质** | 服务器端维护的用户会话数据（通常以 Map 结构存在内存、Redis 或数据库中） |
|
||||
| **认证流程** | 用户登录 → 服务器创建 Session → 将 Session ID 通过 `Set-Cookie` 返回 → 浏览器后续请求自动携带该 Cookie → 服务器通过 Session ID 查找会话数据验证身份 |
|
||||
| **核心特点** | **有状态**：服务器持有用户上下文，可随时主动吊销 |
|
||||
| **定位** | 经典的**服务端主导**的认证方式，适合传统 Web 应用和前后端未彻底分离的场景 |
|
||||
|
||||
**优点**：
|
||||
|
||||
- 简单成熟，几乎所有 Web 框架默认集成
|
||||
- 服务端可随时销毁会话，控制力强
|
||||
- 敏感信息存在服务端，不暴露给客户端
|
||||
|
||||
**缺点**：
|
||||
|
||||
- 扩展性受限——多服务器需共享 Session（引入 Redis 等外部存储）
|
||||
- 依赖 Cookie，纯移动端/非浏览器环境不友好
|
||||
- 容易受到 CSRF 攻击（需额外防护）
|
||||
|
||||
## JWT
|
||||
|
||||
| **本质** | 一段经过签名（或加密）的 JSON 数据，由 Header、Payload、Signature 三部分组成，以 Base64URL 编码 |
|
||||
| ------------ | ------------------------------------------------------------ |
|
||||
| **认证流程** | 用户登录 → 服务器验证凭据并签发 JWT → 客户端存储 Token → 后续请求在 `Authorization: Bearer <token>` 头中携带 → 服务器**仅验证签名和有效期**，无需查库 |
|
||||
| **核心特点** | **无状态**：Token 自身包含用户身份信息，服务器不需要维护会话 |
|
||||
| **定位** | 现代**前后端分离架构**和**多端（Web/iOS/Android）统一接入**的事实标准 |
|
||||
|
||||
**优点**：
|
||||
|
||||
- 天然无状态，服务端可随意水平扩展
|
||||
- 不依赖 Cookie，可用于移动端、小程序等非浏览器环境
|
||||
- 跨域友好（CORS 场景下比 Cookie 更灵活）
|
||||
- Payload 可携带少量业务数据，减少数据库查询
|
||||
|
||||
**缺点**：
|
||||
|
||||
- Token 一旦签发，在过期前无法主动撤销（需引入黑名单/版本号等机制）
|
||||
- Payload 仅 Base64 编码（非加密），敏感信息绝对不能放入
|
||||
- Token 体积比 Session ID 大，每次请求都传输有一定带宽开销
|
||||
|
||||
## SSO
|
||||
|
||||
| 维度 | 说明 |
|
||||
| :----------- | :----------------------------------------------------------- |
|
||||
| **本质** | 一种架构模式，通过**统一的认证中心（IdP）**，让用户在多个独立系统间共享登录状态 |
|
||||
| **认证流程** | 用户访问应用A → 重定向到 SSO 认证中心 → 登录并获取令牌 → 带回令牌访问应用A → 再访问应用B时，认证中心识别已登录状态，直接放行 |
|
||||
| **常见实现** | CAS、SAML、OAuth 2.0 + OpenID Connect |
|
||||
| **定位** | **企业级、多系统生态**的统一身份认证方案 |
|
||||
|
||||
**优点**：
|
||||
|
||||
- 用户体验极佳：一次登录，访问所有关联系统
|
||||
- 集中管理：统一账号体系、权限策略、安全审计
|
||||
- 安全性提升：减少密码泄露面，可配合多因素认证（MFA）
|
||||
|
||||
**缺点**：
|
||||
|
||||
- **单点故障风险**：认证中心一旦宕机，所有系统登录受影响
|
||||
- 实现复杂：涉及协议配置、令牌传递、跨域重定向等
|
||||
- 对认证中心的高可用要求极高
|
||||
|
||||
## OAuth 2.0
|
||||
|
||||
| 维度 | 说明 |
|
||||
| :----------- | :----------------------------------------------------------- |
|
||||
| **本质** | 一种**授权框架**（而非纯粹的认证协议），允许用户授权第三方应用在**不暴露自己密码**的情况下访问受保护资源 |
|
||||
| **核心角色** | 资源拥有者（用户）、客户端（第三方应用）、授权服务器、资源服务器 |
|
||||
| **核心流程** | 用户授权 → 第三方获取授权码 → 换取 Access Token → 持 Token 访问资源 |
|
||||
| **定位** | **第三方接入**和**开放平台**的标准授权方案（微信登录、Google 登录等） |
|
||||
Reference in New Issue
Block a user