GraphQL & Data Analytics
Week7讲了一下REST API Security & Authentication,是week4&5的补充,更多的重点在GraphQL 和 Data Analytics & Machine Learning
REST API Security & Authentication
Security is matters
安全是 非功能性需求(Non-functional requirement),但在真实系统里是“必须有”的。风险取决于 数据敏感度(Data classification):
- Public data:例如 NSW 油价 API —— 任何人路过加油站都能看到价钱 → 对加密与强认证的要求低。
- Sensitive / High-risk data:例如银行客户余额、个人信息(PII)→ 必须有严格的加密、认证、授权。
Week7 主要强调的是Confidentiality + 正确的认证/授权 + 防滥用(rate limiting)
核心安全目标:CIA Triad
- C – Confidentiality(机密性):只有有权限的人/系统可以看到数据
- I – Integrity(完整性):数据不被未授权篡改
- A – Availability(可用性):服务随时可用,不被攻击搞崩(如 DDoS)
加密通道:TLS & HTTPS
TLS(Transport Layer Security) 用于加密 “在传输中(in transit)” 的数据
- 早期用的是 SSL,后面因为 Heartbleed 漏洞被淘汰 → 现在用 TLS1.2+ 为工业标准
- 浏览器访问 HTTP(非 HTTPS)时会给出“不安全”提示
- 对 API 来说:
- 推荐:所有对外 API 都使用 HTTPS(TLS1.2+)
- 这样即使有人抓 Wi-Fi 数据包,也只能看到加密内容,无法读懂。 “要保护 数据在路上(in transit) 不被窃听 → 用 TLS(HTTPS)”
Authentication vs Authorization(重点区分)
- Authentication(认证):你是谁?
- 类比:输入 zID + 密码登录 myUNSW
- 不通过 → API 应返回 401 Unauthorized
- Authorization(授权):你能干什么?
- 例如:你能登录 WebCMS,但你不能删 lecture slides(那是老师权限)
- 权限不够 → API 应返回 403 Forbidden
401 = 没登录 / 身份无效403 = 登录了,但你没这个权限
常见认证方式(Authentication Methods)
1. HTTP Basic Authentication
- 客户端每次请求时,在 Header 里放一个 Base64 编码的
username:password - 特点:
- 简单、老牌、很多 HTTP 客户端都直接支持
- Base64 是 encoding,不是 encryption,任何人都能轻松解码
- 同一个密码会被重复发送很多次 → 攻击窗口大(attack window)
可以和 TLS 搭配使用:
Basic Auth + HTTPS,但总体依然不算安全。
2. Token-based Authentication(令牌)
“用户只在第一次用密码登录,之后用短期令牌(token)证明自己。”
最典型实现:JWT(JSON Web Token)
JWT 结构(通常由 3 段组成):
- Header(头部,Base64 编码)
- 指明:type = JWT, alg = HMAC / RSA 等签名算法
- Payload / Claims(载荷,Base64 编码)
- 包含用户信息、过期时间(exp)、scope 等
- Signature(签名)
- 利用 Header + Payload + 服务器端 secret 做哈希(HMAC)
- 服务器只需重新计算一次哈希,比解密更快
- 无状态(stateless):服务器不需要存 session
- 可设置过期时间(expiry) → token 被偷也只在短时间内有效
- 搭配 TLS 使用更安全
3. API Key
- 用于 Application ↔ Application 之间认证(不是用户级别)
- 场景例子:
- 你在 Assignment 2 中调用外部公共 API,需要注册获取一个 API Key
- API Key 是一个 长随机字符串,代表“哪个客户端在调用我的 API”
用途:
- Usage analytics:记录每个 Key 的请求次数
- Rate limiting:限制每个 Key 每分钟/每天最多请求数
- Subscription plans:根据付费档控制配额(basic / premium / pro)
不要把 API Key:
- 放在公开 GitHub 仓库
- 放在 URL query string 里(会被各种 proxy / log 记录下来)
- 建议放在:
- HTTP Header
- 或加密的配置文件 / 环境变量中
4 OAuth 2.0(第三方授权)
解决问题:
“我不想把密码给第三方应用,但又想让它访问我的部分数据。”
典型例子:
“用 Google / Facebook 登录某网站(Social Login)”
流程核心思想:
- 用户访问第三方应用 B(例如某 SaaS)
- B 跳转到 Google/Facebook 认证页面,让用户登录并确认授权
- 用户同意后,Google 生成 Access Token(访问令牌)
- 应用 B 用这个 Token 去访问用户在 Google 那里的数据(例如 name / email)
- Token 有 有效期(expiry),过期需要 Refresh 或重新授权
关键点:
- 用户的真实密码只提交给 身份提供者(IdP),不会流向应用 B
- OAuth 支持 Scope(权限范围),例如:
- 只要
email和profile - 不要
birthday或contacts
- 只要
“OAuth 通过 Access Token + Scope + Expiry 实现安全的、可控的第三方授权认证,不破坏 REST 的 无状态性。”
其他重要安全实践
Rate Limiting(限流)
- 防止 Denial of Service (DoS) / Distributed DoS (DDoS)
- 常见策略:
- 每 IP / 每 API Key 每分钟最多请求 N 次
- 超出返回 429 Too Many Requests
- 严重滥用 → 直接封禁 / 撤销 API Key
限制 HTTP Methods
- 白名单方式(Whitelist permitted HTTP methods)
- 例如一个只读天气 API,完全不应该开放
DELETE/PUT - 对不允许的方法直接返回 405 Method Not Allowed
输入验证(Input Validation)
- 防止 SQL Injection、代码注入等
- 要求:
- 对所有外部输入参数做类型检查 / 白名单校验
- 使用 参数化查询(Parameterized Queries),不要字符串拼接 SQL
- 可使用 validation library(如 Python 的
validator-collection或框架内建校验)
不要在 URL 里传敏感信息
- 包括:
username,password,api_key,token - 原因:
- URL 会被各种 router、proxy、server log 记录 → 泄露风险极高
- 应使用:
- HTTP Header
- 或 request body(POST/PUT)
Logging & Error Messages
- 要记录日志(Audit Logs):谁在什么时候访问了什么、是否成功、是否异常
- 但错误信息不要过度暴露内部信息:
- ❌:
MySQL 5.6.12 error on table user_credentials ... - ✅:
Database error. Please contact administrator.(内部日志可以更详细)
- ❌:
“Hack your API before others hack you”
- 使用安全测试工具(Web security tools):
- Burp Suite(社区版)
- OWASP ZAP
- 注意:
- 只测试你自己或明确允许测试的系统
- 否则可能违法(不要对 Facebook / Twitter 随便扫)
什么是 GraphQL?
“GraphQL 是一种 API 查询语言(Query Language for APIs) 和 运行时(Runtime),允许客户端精准地请求他们需要的数据——不多不少。”
- 对客户端来说:可以指定想要的字段结构
- 对服务端来说:通过 schema 实现强类型、可演进的 API
GraphQL会尝试克服一些REST的限制
- 固定的结构数据交换: REST会要求客户端严格遵守固定结构接收资源,易于使用,但不是最有效的
- 超额获取和获取不足:REST API总是会返回整个数据集,会获取一些你用不到的信息。所以开发人员需要大量代码处理API请求容易影响性能和用户体验。
GraphQL 是作为一种基于查询的解决方案出现的。查询只需一次API请求和响应交换即可返回确切的数据。
REST vs GraphQL相似
架构
- 都是无状态的,因此服务器不会在请求之间保存响应历史记录
- 两者都使用客户端-服务器模型,因此来自单个客户端的请求会导致来自单个服务器的回复
- 都是HTTP,因为 HTTP 是底层通信协议
- 都支持缓存。因此,客户端和服务器可以缓存经常访问的数据以提高通信速度。
基于资源设计 (URI, HTTP方法, API访问)
数据交换 (JSON, XML, HTML)
语言和数据中立性 (适用任何数据库和编程语言)
REST vs GraphQL 对比总表
| 维度 | REST | GraphQL |
|---|---|---|
| 本质 | 资源风格的 API 设计规则(Architectural Style) | Query Language + Runtime |
| Endpoint 数量 | 多个 endpoint(每个资源一个 URL) | 通常只有一个 endpoint(例如 /graphql) |
| 返回数据结构 | 服务器定义,结构固定 | 客户端通过 query 定义,结构灵活 |
| 类型系统 | Weakly typed | Strongly typed schema |
| 错误检查 | 客户端负责检查返回数据是否合法 | Schema 自动验证,非法请求会被拒绝并给出 error message |
| 适用场景 | 资源清晰、需求比较稳定的场景 | 数据复杂、关联多、前端需求多样的场景 |
核心概念:Field & Query
示例 Query:
query {
hero(id: "1000") {
name
# Queries can have comments!
friends {
name
}
}
}可能返回:
{
"hero": {
"name": "R2-D2",
"friends": [
{ "name": "Luke Skywalker" },
{ "name": "Han Solo" },
{ "name": "Leia Organa" }
]
}
}- Response 的结构 = Query 中请求的字段结构(what you ask is what you get)
- 可以跨多个底层资源(user, friends, posts…),对客户端是透明的
GraphQL 三种 Operation Type
- Query
- 用于 读数据(Read)
- 类比 REST 的
GET
- Mutation
- 用于 创建 / 更新 / 删除 数据
- 类比
POST/PUT/DELETE
- Subscription
- 用于 实时更新 / 推送(Realtime updates)
- 常用于聊天、通知、直播等场景
GraphQL 的优点(Advantages)
- Efficient data fetching(高效数据获取)
- 一个请求就能拿到多个资源的字段,避免“多次请求”(over-fetch & under-fetch 问题)
- Strongly typed schema
- 客户端知道有哪些字段、类型是什么
- 服务器在执行前通过 schema 验证 query 是否有效
- Single endpoint
- 所有请求都打到同一个 URL
- 不再需要
v1/users、v2/users一堆 endpoint
- Easy evolution
- 增加字段不破坏旧客户端,只要 schema 做好兼容即可
- 不需要频繁版本化(v1/v2)
- Better developer experience
- 工具链强,比如 GraphiQL, Playground 可以自带文档和自动补全
GraphQL 的缺点(Disadvantages)
- Giving the power to the requester can be dangerous
- 客户端可以写 “非常深、非常复杂” 的 query
- 可能导致:
- 对数据库的多次访问(N+1 问题)
- CPU / 内存压力,甚至 DoS
- Schema design overhead
- 必须先设计好类型系统和 schema
- 不熟悉的人上手成本比 REST 高
- Complexity overhead
- 对于简单 CRUD 场景,REST 反而更简单
- GraphQL 适合“复杂数据 + 多样化前端需求”的场景
- Caching challenges
- REST 常见:
GET /users/1很适合用 HTTP cache / CDN - GraphQL 每个查询都可能不一样(不同字段组合)→ 很难在 HTTP 层直接缓存
- REST 常见:
- Error handling complexity
- REST:通过 HTTP status code(200 / 400 / 404 / 500)处理
- GraphQL:通常 HTTP 还是 200,错误写在返回 body 的
errors字段里 → 客户端逻辑更复杂
Data Analytics & Machine Learning
Data-driven Organizations(数据驱动组织)
数据分析用于将原始数据转化为可行的见解。它包括一系列工具、技术和过程,用于通过使用数据来发现趋势并解决问题。数据分析可以塑造业务流程,改善决策,促进业务增长。
企业把“数据”当成资产,用数据来指导:决策 → 行动 → 评估 → 迭代
数据分析的目标:
- 理解过去发生了什么(what happened)
- 找到原因(why)
- 预测未来(what will happen)
- 给出建议(what should we do)
四种类型的 Analytics【Types of Analytics】
- Descriptive Analytics(描述性分析)特征是数据可视化
- 问题:What happened?
- 举例:过去一年每月销售额曲线
- Diagnostic Analytics(诊断性分析)用于了解某些情况发生的原因
- 问题:Why did it happen?
- 举例:销量下滑是因为价格上涨还是广告减少?
- Predictive Analytics(预测性分析) 预测未来
- 问题:What is likely to happen?
- 举例:根据历史数据预测下季度的销售额
- Prescriptive Analytics(规范性/处方性分析)对结果的最佳响应和提供建议
- 问题:What should we do?
- 举例:给出最优定价策略或库存策略
机器学习基本定义(What is Machine Learning)
机器学习(Machine Learning, ML)是让系统通过数据自动学习规律,并在没有显式硬编码规则的情况下进行预测/决策。
- Feature(特征):描述一个样本的属性,如房价预测中的卧室数、面积。
- Sample(样本):单个数据实例,如 CSV 中的一行(一个房子)。
- Feature Vector(特征向量):由多个特征组成的向量 [x1,x2,…,xn]。
- Training set(训练集):用于训练模型的数据。
- Feature Extraction(特征提取):从原始数据中抽取有用特征,例如从文本中提取词频。
基本统计概念(Statistics Essentials)
基本这这门课中会经常计算的,然后用什么数去分析,比如说异常值
- Mean(均值):平均值
- Median(中位数):排序后中间那个数
- Mode(众数):出现次数最多的值
- Variance(方差):数据相对于均值的平方偏差的平均,方差越大说明数据波动越大衡量“散布程度”
- Standard Deviation(标准差):方差的平方根,更直观的离散度量
- Covariance(协方差):协方差为正,表示两个变量是正相关关系,即当一个变量增加时,另一个变量也增加;如果协方差为负,表示两个变量呈负相关关系,即当一个变量增加时,另一个变量减少;如果协方差为零,表示两个变量之间没有线性关系
- Correlation(相关系数):介于 -1 和 1,衡量两个变量线性关系的强弱和方向
- Bayes’ Theorem(贝叶斯定理):用“先验概率 + 观察数据”来更新“后验概率”
ML 在 Data Analytics 中的一般流程

- Prepare Data(准备数据)
- 清洗缺失值、异常值,特征工程
- Define & Initialize Model(定义模型)
- 选择算法(如 Linear Regression、Logistic Regression、KNN、SVM…)
- Train Model(训练)
- 在训练集上调整参数,使模型拟合数据
- Validate Model(验证)
- 用测试集评估模型性能(accuracy、RMSE、F1-score 等)
- Use / Deploy(使用或部署)
- 嵌入到 web service(例如你的 API 中做预测)
- Update & Revalidate(更新与再验证)
- 随着数据变化定期重训与评估
机器学习方法分类(Machine Learning Methods)
Supervised Learning(监督学习)
- 训练数据有“标签”(label)
- 目标:学习一个映射 f(x)→y
- 两种主要任务:
- Regression(回归):预测连续值(如价格、温度)
- Classification(分类):预测离散类别(如 spam / not spam)
Unsupervised Learning(无监督学习)
- 数据没有标签
- 目标:发现数据结构或隐藏模式
- 典型任务:
- Clustering(聚类):自动分组相似样本(如客户细分)
线性回归(Linear Regression)
模型形式:
- y:目标变量(如房价)
- x:输入特征(如面积)
- β0,β1:模型参数(截距和斜率)
- ϵ:误差项
训练目标:
找到一条最合适的直线,让所有训练点到直线的垂直距离的平方和最小(最小二乘法)。
扩展:
- Multiple Linear Regression:多个特征
- Polynomial Regression:在原特征上做多项式扩展,拟合非线性关系
Classification(分类)
- 监督学习任务,有标签
- 模型输出一个类别,例如:
- 是否违约(yes / no)
- 图像是猫还是狗
- 常见算法:
- Logistic Regression
- k-NN(k-Nearest Neighbors)
- SVM(Support Vector Machine)
- Decision Tree / Random Forest
Clustering(聚类)
- 无监督学习
- 自动将样本划分成若干簇(cluster)
- 特点:
- 同簇样本彼此相似(similar)
- 不同簇之间差异较大
- 常见算法:
- K-Means Clustering
- Hierarchical Clustering
- DBSCAN 等
发表回复
要发表评论,您必须先登录。