接口 API

点击预约会议室后，页面发送会议室编号和预约时段。API 规定请求怎么写，也规定成功或失败要返回什么。

• 请求表达意图：要预约哪间会议室，以及预约哪个时段。
• 结果来自服务端：页面根据返回的状态显示已预约或错误原因，而不是自己猜测结果。

API 规定页面怎样和服务端交换数据，前端负责把输入和结果显示出来，JSON 是常见的数据写法。三者可能一起出现，但职责并不相同。

• API 不等于 前端 Frontend：API 规定交换数据的入口、方法、字段和结果，前端负责页面和交互。
• API 不等于 JSON：API 是双方的办事约定，JSON 只是装载对象、数组和字段的一种格式。
• 看到一个 URL 还不够，还要确认方法、允许字段、成功结果和失败结果。

验收 API 时，要能分别找到入口、允许提交的字段、服务端规则和返回结果。它们共同构成可被调用方依赖的契约。

• 方法和路径说明从哪里调用，以及这次调用要做什么。
• 请求字段说明页面可以提交什么，契约规则说明哪些结果必须由服务端确认。
• 稳定响应同时覆盖成功和失败，让页面知道下一步该显示结果、保留输入还是允许修正。

同一个预约接口可能返回成功或拒绝。调用方不猜结果，而是按照稳定的状态码、错误码和响应体处理当前页面。

• 正常预约返回 200 OK 和 confirmed，页面可以显示已预约并保留服务端结果。
• 权限检查失败返回 403 BOOKING_FORBIDDEN，页面保留可以修改的内容，并把错误转成用户能处理的提示。

判断是否需要 API，要看这个结果会不会被其他页面、端或服务继续使用，而不是看它看起来像不像一个按钮。

• 输入格式提示、当前字段是否完整等只影响页面自己的小状态，可以先留在前端。
• 预约状态、预约编号和错误原因会被列表页与管理端读取，应由 API 统一确认并返回。

请实现会议室预约 API：浏览器调用 POST /api/meeting-rooms/2048/book，只提交 roomId 和 slot。服务端从当前登录会话判断用户，检查预约权限和会议室状态；不要接受客户端传入 userId、confirmedAt 或最终状态。成功返回 200 OK、roomId 和 confirmed；失败返回稳定错误码，并保留页面中可以修改的内容。不要把密码、令牌或内部堆栈返回给浏览器。验收时同时检查成功和失败响应、字段边界、权限来源以及浏览器不应看到的敏感信息。