第三方在线 API

在 google AI studio 中，虽然只能生成浏览器封装环境下的前端页面，但是实际上可以请求第三方的API。由于 google AI studio 本身所处于 HTTPS 环境中，因此请求的对象也必须要是 HTTPS 协议的 API，不能是 HTTP 协议，同时要支持 CORS 跨域访问请求。

（一）封装好的公开 API

有一些 现成的、支持 HTTPS 且可直接在浏览器中请求 的第三方在线 API，可用于你在 Gemini AI Studio 或本地前端沙盒里测试跨域 HTTP(S) 请求（例如随机返回布尔值、假数据等）。这些 API 不需要你自己搭后端服务器，并且大部分都支持 CORS + HTTPS，可直接通过 fetch() 调用。(Public APIs)

1) Yes/No 随机 API

这是一个专门返回随机 “yes” 或 “no” 的公共测试 API：

GET https://yesno.wtf/api

它返回 JSON 对象，例如：

{"answer":"yes",
 "forced":false,
 "image":"https://yesno.wtf/assets/yes/7-653c8ee5d3a6bbafd759142c9c18d76c.gif"
}

这里 answer 字段是随机的 yes 或 no，几乎可以满足你 “随机布尔值” 的测试需求。（注意：虽然不是严格 true/false，但可在前端按需求映射成布尔值）

可以直接用 curl 命令调取

2) DummyJSON 假数据 API

提供一系列真实 HTTPS 可访问的假数据接口（用户、任务、帖子等）。例如：

GET https://dummyjson.com/todos

会返回 To-Do 任务列表 JSON，适合展示用。(DummyJSON)

{"todos":[
    {"id":1,"todo":"Do something nice for someone you care about","completed":false,"userId":152},
    {"id":2,"todo":"Memorize a poem","completed":true,"userId":13},
    {"id":3,"todo":"Watch a classic movie","completed":true,"userId":68},
    ...
    {"id":27,"todo":"Learn Express.js","completed":false,"userId":194},
    {"id":28,"todo":"Learn calligraphy","completed":false,"userId":80},
    {"id":29,"todo":"Have a photo session with some friends","completed":true,"userId":91},
    {"id":30,"todo":"Go to the gym","completed":true,"userId":142}],
 	"total":254,
 	"skip":0,
 	"limit":30}

3) JSONPlaceholder（经典测试 API）

GET https://jsonplaceholder.typicode.com/posts/1

{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
}%

这是业界最常用的公共测试 API 之一，用于演示按钮、UI + HTTP 交互等。它是 HTTPS、无授权且支持 CORS 的。(Public APIs)

4) mock API 工具（可自定义）

服务如 Beeceptor 可以让你自定义任何路径和返回内容：

访问 https://beeceptor.com 创建 mock 接口
配置你想返回的 GET /random JSON
得到一个 HTTPS 可访问的 API 域名

并且 Beeceptor 的 mock 接口默认支持 CORS，从前端可以直接调用。(Beeceptor)

fetch 是 JavaScript 内置的 HTTP 客户端 API**，用于在前端代码中**向服务器发起网络请求（HTTP/HTTPS）并获取响应。相当于python 中的 requests

最小示例（GET 请求）
fetch("https://yesno.wtf/api")
  .then(response => response.json())
  .then(data => {
    console.log(data);
  });
执行流程是：

浏览器向目标 URL 发起 HTTPS GET

返回一个 Response 对象

调用 .json() 解析响应体

得到 JS 对象

返回结果：
const resp = await fetch(url);
resp 不是数据本身，而是一个 Response 对象：

属性 / 方法含义
resp.ok HTTP 状态是否 2xx
resp.status 状态码（200 / 404 / 500）
resp.json() 解析 JSON
resp.text() 解析文本
resp.headers 响应头

示例：
const resp = await fetch(url);
if (!resp.ok) throw new Error(resp.status);
const data = await resp.json();
fetch 不是万能的，它受限于浏览器安全模型：

HTTPS 页面 ❌ 请求 HTTP API

对方服务器不允许跨域 → 请求失败

属性 / 方法	含义
`resp.ok`	HTTP 状态是否 2xx
`resp.status`	状态码（200 / 404 / 500）
`resp.json()`	解析 JSON
`resp.text()`	解析文本
`resp.headers`	响应头

（二）原理：CORS

CORS 不是服务器的安全机制，而是浏览器的安全机制。

服务器“是否支持 CORS”，本质上只是： 👉 服务器是否在响应中写了浏览器看得懂的“放行指令”。

1. 早期 Web 的致命问题

浏览器最早允许 JS 随意请求任意网站：

fetch("https://bank.com/api/balance")

如果没有限制，会发生什么？

恶意网站：
- 偷 cookie
- 偷登录态
- 读银行数据
CSRF + 数据窃取 = 互联网灾难

于是浏览器引入了：

Same-Origin Policy（同源策略）

2. 什么是「同源」？

三个要素必须完全一致：

要素	示例
协议	https
域名	api.example.com
端口	443

只要有一个不同 → 跨域

示例对比

页面	API	是否同源
https://a.com	https://a.com	✅
https://a.com	http://a.com	❌（协议不同）
https://a.com	https://b.com	❌
https://a.com:443	https://a.com:8080	❌

3. 那为什么现在“又能跨域了”？

CORS = 浏览器向服务器“询问是否允许跨域访问”的一套标准协议

关键点：

请求一定会发出去
服务器一定会收到
浏览器决定：要不要把响应交给 JS

4. CORS 的核心机制

实际发生的事情

浏览器发请求（带 Origin）
服务器返回响应（带 CORS Header）
浏览器检查 Header
❌ 不满足 → JS 拿不到数据 ✅ 满足 → JS 正常读取

1️⃣ Origin（浏览器自动加）

Origin: https://ai.google.dev

告诉服务器：请求是从哪里来的
JS 不能修改

2️⃣ Access-Control-Allow-Origin（服务器返回）

Access-Control-Allow-Origin: https://ai.google.dev

含义：

“我允许这个 Origin 访问我”

⚠️ 这是 最核心的一条

常见写法

写法	含义
`*`	允许任何来源（有限制）
`https://xxx.com`	只允许指定来源
不返回	❌ 浏览器直接拦截

3️⃣ Access-Control-Allow-Methods

Access-Control-Allow-Methods: GET, POST

限制 HTTP 方法

4️⃣ Access-Control-Allow-Headers

Access-Control-Allow-Headers: Content-Type, Authorization

是否允许自定义请求头

5️⃣ Access-Control-Allow-Credentials（高级）

Access-Control-Allow-Credentials: true

是否允许携带 Cookie / Token
⚠️ 此时 Allow-Origin 不能是 \*

6. 「预检请求」（Preflight）

你经常看到的：

OPTIONS https://api.example.com/xxx

出现的情况为请求 “不够简单”：

非 GET / POST / HEAD
自定义 Header
Content-Type: application/json
带 Authorization

预检流程（非常关键）

浏览器先发：

OPTIONS /api
Origin: https://ai.google.dev
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

服务器回应：

Access-Control-Allow-Origin: https://ai.google.dev
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Authorization

浏览器点头 → 才会发真正请求

7. CORS ≠ 请求被服务器拒绝

你可能以为：

“CORS 失败 = 服务器拒绝请求”

这是错的。

真实情况是：

位置	行为
网络层	请求 ✔ 已到服务器
服务器	✔ 正常返回
浏览器	❌ 不把结果交给 JS

所以你会看到：

DevTools Network：200 OK
Console：CORS error

（三）原理：为什么禁止HTTPS调用HTTP

浏览器之所以禁止 HTTPS 页面去调用 HTTP 资源（你这里是 fetch("http://...")），核心原因不是“CORS”，而是 Mixed Content（混合内容） 规则：它是浏览器在 HTTPS 安全模型里必须强制执行的一条底线。

下面从威胁模型、浏览器行为、例外情况与工程替代方案，把它讲透。

HTTPS 的安全性建立在“端到端加密 + 完整性校验 + 身份认证”上。 一旦在 HTTPS 页面里允许加载 HTTP 资源，就等于在安全链条中插入了一个“明文、可被篡改的环节”。 攻击者不需要攻破 HTTPS，只要劫持那段 HTTP，就能间接控制 HTTPS 页面或窃取数据。

1. 威胁模型：为什么 HTTP 会破坏 HTTPS？

HTTPS 给你三件事

机密性（Confidentiality）：中间人看不到内容
完整性（Integrity）：中间人改了会被发现
身份认证（Authentication）：你确实连到目标服务器，而不是假冒

HTTP 三件都没有

明文传输：任何在路径上的设备都能看、能改
没有强校验：内容可被替换
没有可信身份：DNS/路由劫持后你甚至不知道对方是谁

最典型的攻击：HTTP 资源被篡改 → HTTPS 页面被接管

假设你的页面是：

页面：https://yourapp.com
你在页面里请求：http://api.yourapp.com/random

攻击者在用户的网络路径上（公共 Wi-Fi、运营商、公司代理、恶意路由器）做 MITM，能把 HTTP 响应改成任何东西。

2. Mixed Content 分两类

浏览器把“HTTPS 页面加载 HTTP”称为 Mixed Content，并严格分级处理：

A) Active Mixed Content（主动/可执行内容）——默认直接阻止

包括：

<script src="http://...">
fetch("http://...")
XMLHttpRequest("http://...")
WebSocket ws://...
<iframe src="http://...">（多数情况下）

原因：它们能影响页面行为、执行代码、读写数据，风险极高。

B) Passive Mixed Content（被动/展示型内容）——早期可能允许，现也越来越严格

包括：

<img src="http://...">
<video src="http://...">
<audio src="http://...">

风险相对小，但也可能造成：

用户隐私泄露（请求会暴露用户 IP、Referer）
跟踪像素
内容投毒（替换图片误导用户）
部分场景下还能被用作侧信道攻击

所以现代浏览器对这类内容也在逐步收紧或给出强警告。

（四）WebSocket 实验室

WebSocket 实验室：我增加了一个全新的 WebSocket 模块。它连接到一个公网 Echo 测试服务器 (wss://echo.websocket.org)。连接成功后，你发送的任何文本，服务器都会实时回传给你。

（一）封装好的公开 API​

1) Yes/No 随机 API​

2) DummyJSON 假数据 API​

3) JSONPlaceholder（经典测试 API）​

4) mock API 工具（可自定义）​

（二） 原理：CORS​

1. 早期 Web 的致命问题​

2. 什么是「同源」？​

3. 那为什么现在“又能跨域了”？​

4. CORS 的核心机制​

5. 最关键的 Header​

6. 「预检请求」（Preflight）​

7. CORS ≠ 请求被服务器拒绝​

（三）原理：为什么禁止HTTPS调用HTTP​

1. 威胁模型：为什么 HTTP 会破坏 HTTPS？​

2. Mixed Content 分两类​

（四）WebSocket 实验室​