REST API
REST API 是一种按资源组织接口的设计方式，通常用 URL 指向资源、用 HTTP 方法表达操作。它解决前端与后端如何约定数据访问方式的问题，比如让任务 App 用同一组接口查询、新建和修改任务。
你可能会说：「帮我做一组接口，让网页能查询、新建和修改任务，调用方式尽量统一。」
动手看看任务工作台的接口记录
切换操作，对照左侧结果与右侧请求。这里是独立的成功场景快照，不会真的联网；默认用 GET 查询任务集合，URL 指向资源，方法表达操作。
要点REST API 是怎么组织接口的？
- 1
先确定要操作的资源
假设你在做任务 App，任务就是一种资源。我们可以用 /tasks 表示任务集合，用 /tasks/42 表示其中一条任务。这样前端看到地址，就能知道请求针对什么，而不必从接口名里猜。
- 2
用请求方法表达操作
同一个资源地址可以配合不同的 HTTP 方法：GET 获取任务，POST 在集合中创建任务，PATCH 修改某条任务，DELETE 删除它。因为地址和操作各有分工，接口会更容易查找和维护。
- 3
每次请求带齐所需信息
REST 强调请求之间无状态：服务端不能只靠记住上一次请求，才能理解这一次要做什么。比如查询任务详情时，请求要明确给出任务编号；如果接口需要身份信息，这次请求也要能提供。
容易混淆的地方
API 是系统对外提供能力的统称，REST API 只是其中一种组织方式。它也不等于“返回 JSON 的 HTTP 接口”：返回格式是数据如何呈现，REST 更关注资源、操作和请求之间的约定。GraphQL 则通常让客户端在一次查询中指定需要哪些字段，适合比较两者时从数据获取方式入手。
什么时候用
适合用
- 做任务管理网站时，前端需要查询任务列表、创建任务、修改状态，并与后端约定稳定的调用方式。
- 给管理后台开放客户资料接口，让网页和手机 App 都能按同一套资源地址获取或更新数据。
- 让 AI Agent 对接已有业务系统时，系统提供了按资源组织的 HTTP 接口，可供它查询和操作记录。
不适合用
- 只是做一个静态展示页，内容随网站一起发布，没有独立的数据读写需求，用静态文件就够了。
- 做双人协作白板，双方需要持续接收对方的操作；实时双向通信更适合考虑 WebSocket。
- 页面只需要跳转到另一个网址，不涉及读取或修改服务端数据，直接使用链接。
练一练选一个答案，看看解释
你在做任务 App，要让前端获取编号为 42 的任务，并能修改它的标题。哪种接口设计最符合 REST API 的思路？
让 AI 帮你做复制给 AI Agent 直接用
请为任务 App 设计一组 REST API：支持查询任务列表与详情、创建任务、修改标题和删除任务。请列出每个接口的 HTTP 方法、资源路径、请求数据、响应示例和常见错误状态；说明哪些操作需要登录，并保持路径命名一致。