PostgREST不能直接接收XML请求；它仅支持application/json（或text/plain），遇application/xml返回415错误，所有请求体均按JSON解析并映射为SQL操作，XML处理必须由前置服务转换为JSON后转发。
PostgREST 本身不支持直接接收或解析 XML 数据——它只接受 JSON 请求体，并将数据库视图/表映射为 REST 资源。想用 PostgREST 处理 XML，必须在外部做转换，不能靠它“暴露视图并自动处理 XML”。
PostgREST 能否直接接收 XML 请求？
不能。POST、PATCH 等请求的 Content-Type 必须是 application/json（或 text/plain 仅用于简单字符串）。如果客户端发 application/xml，PostgREST 会返回 415 Unsupported Media Type 错误。
- PostgREST 的 HTTP 层不包含 XML 解析器
- 所有请求体都按 JSON 解析，然后映射到 SQL 的
INSERT/UPDATE参数 - 即使视图有
INSTEAD OF INSERT触发器，输入仍是 JSON 格式，不是原始 XML
如何让视图“看起来支持 XML”？
只能靠反向代理或前置服务做 XML → JSON 转换。例如 Nginx 或 Cloudflare Workers 拦截 application/xml 请求，调用 XSLT 或轻量解析器转成等价 JSON，再转发给 PostgREST。
- 关键点：XML 结构需能明确映射到目标视图的字段（如
Alice a@b.c {"name":"Alice","email":"a@b.c"}） - 复杂嵌套或重复元素（如多值
A B - PostgREST 的视图必须可插入（
INSERT可执行），且字段名与 XML 标签名严格对应（或通过json_to_record()在触发器里重映射）
有没有绕过 JSON 的“伪 XML 支持”？
有但极不推荐：把 XML 当作纯文本存入 TEXT 字段，再用 PostgreSQL 的 xmlparse() 在函数或视图中解析。这会让业务逻辑泄漏到 SQL 层，且无法利用 PostgREST 的自动 CRUD。
CREATE OR REPLACE FUNCTION handle_xml_payload(payload TEXT)
RETURNS TABLE(name TEXT, email TEXT) AS $$
SELECT
(xpath('//name/text()', xmlparse(content payload)))[1]::TEXT,
(xpath('//email/text()', xmlparse(content payload)))[1]::TEXT;
$$ LANGUAGE sql;
- 调用方式只能是
GET /rpc/handle_xml_payload?payload=%3Cuser%3E%3Cname%3EAlice%3C/name%3E%3Cemail%3Ea%40b.c%3C/email%3E%3C/user%3E—— URL 编码严重，不可读 - 无法用
POST提交原始 XML body；必须把整个 XML 塞进 query string 或 JSON 字符串字段里 -
xpath()性能差，无命名空间支持，错误反馈模糊（空数组 or NULL）
真正可行的路径只有一条：别让 PostgREST 碰 XML。用一个轻量服务（比如 Python + fastapi 或 Node.js + xml2js）收 XML、校验、转 JSON，再 fetch() 转发给 PostgREST。PostgREST 的强项是“数据库即 API”，不是“任意格式网关”。
