小企业信息化系统开发
小微企业用 PostgREST 把 PostgreSQL 直接变成 REST API：只读接口、行级权限与内部数据对接
2026年10月11日
用 PostgREST 把 PostgreSQL 直接映射为只读 REST API，零后端实现内部数据对接。
小微企业用 PostgREST 把 PostgreSQL 直接变成 REST API：只读接口、行级权限与内部数据对接
摘要：小团队常需要一个轻量数据接口给内部报表、小程序或第三方系统对接，但写一套后端太重。PostgREST 能把现有 PostgreSQL 直接映射成标准 REST API，零业务代码、随表出接口，本文讲清部署、权限与加固。
一、为什么小团队需要一个"轻量数据接口层"
很多小微企业的数据躺在 PostgreSQL 里：订单、客户、库存。某天老板想要手机看实时销售额，或门店小程序要拉商品列表，或财务要导出对账——传统做法是招人写个 Spring/Node 后端，做鉴权、分页、联表，周期长、维护累。更现实的需求是"给我一个能查、能过滤、但不能误删的 HTTP 接口"。这正是 PostgREST 的定位：它不写业务逻辑，只把数据库 Schema 暴露成符合 OpenAPI 风格的 REST 端点，开发量从"写服务"降到"设计好表结构和视图"。
二、PostgREST 是什么：它不做后端，只做映射
PostgREST 是一个用 Haskell 写的独立二进制，启动后连上数据库，把你指定的 Schema 里的表和视图自动生成成 REST 资源。例如表 orders 直接对应 GET /orders，支持过滤 ?status=eq.已付、分页 ?limit=20&offset=0、排序 ?order=amount.desc、关联 ?select=id,customer(name)。它完全复用 PostgreSQL 的能力：权限用数据库的 Role 和行级安全策略（RLS）控制，校验用字段类型和约束，连聚合都能通过视图暴露。换句话说，安全边界和业务语义由数据库保证，PostgREST 只负责"翻译 HTTP 到 SQL"，攻击面小、性能好（单个连接池，毫秒级响应）。
三、10 分钟跑起来：Docker 部署与关键配置
最省事的部署是 Docker。核心配置写在 postgrest.conf：
db-uri = "postgres://web_anon:密码@db:5432/mydb"
db-schemas = "api"
db-anon-role = "web_anon"
server-port = 3000
docker run 挂载配置并映射 3000 端口即可。关键点：1) 专门建一个只读角色 web_anon 作为匿名访问身份，绝不用超级用户；2) 只暴露 api 这个 schema，把内部表放在别的 schema，需要对外开放的做成视图放进来；3) db-anon-role 决定未带 Token 时的身份，配合 RLS 可实现"未登录只能看公开数据"。启动后 curl localhost:3000/orders 就能拿到 JSON，无需写一行后端代码。
四、用 Schema 与角色隔离控制只读/读写权限
权限设计是重点。推荐三层角色：匿名角色 web_anon（只读，用于公开查询）、登录角色 app_user（通过 JWT 携带，可写特定表）、内部角色 service_role（供真正后端使用，绕过 RLS）。只读场景只需给 web_anon 授 SELECT 并开启表的行级安全：
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY "公开已付订单" ON orders
FOR SELECT TO web_anon USING (status = '已付');
这样即使接口暴露，也只会返回已付订单，未付和金额明细被 RLS 挡住。写操作建议只通过视图的 INSTEAD OF 触发器开放，或要求 JWT 登录，避免匿名写入。权限全在数据库一端，PostgREST 不另搞一套，审计清晰。
五、前端怎么调：过滤、分页、关联与聚合
前端对接极其简单。列表：GET /products?select=id,name,price&order=price.desc&limit=20。精确查：?category=eq.数码。范围：?created_at=gte.2026-01-01。模糊：?name=like.*耳机*。多条件用 and=(status.eq.已付,amount.gt.100)。关联查询靠外键：?select=id,customer(name,phone)，一次拿到订单与客户。统计用视图封装：CREATE VIEW sales_daily AS SELECT date, sum(amount) FROM orders GROUP BY date;，前端 GET /sales_daily 即得。对研发来说，相当于"表结构即接口文档"，前后端联调成本大幅下降，特别适合 1~3 人的小团队快速交付内部工具。
六、安全加固：反向代理、JWT 与限流
直接裸跑不建议上公网。生产做法：1) 前面放 Nginx/Caddy 反代，只放行 443，强制 HTTPS；2) 用 JWT 做身份认证，PostgREST 原生支持 postgrest.role claim 切换角色，密钥配 jwt-secret；3) 反向代理层加限流（如 Nginx limit_req）防刷；4) 关闭匿名写权限，所有写操作要求 JWT；5) 定期用 pg_dump 备份，接口只读角色无法破坏数据。若只在内网使用，绑定到 VPN 或内网网段即可，配合 RLS 已经很安全。
七、典型落地场景与替代方案对比
适合的场景：内部数据大屏、小程序只读拉取、第三方系统单向同步、运营临时取数。不适合的场景：复杂多步事务、需要外部 API 调用的业务流程、强校验规则——这些仍应写常规后端。和同类方案比，PostgREST 比手搓 CRUD 快十倍但灵活性低；比 Hasura 轻（Hasura 带 GraphQL 和更强调实时订阅，资源占用更高）；比 Supabase 简单（Supabase 内置了 PostgREST 加 auth 和存储，开箱即用但绑定其体系）。小团队若已有 PostgreSQL，PostgREST 是"最低成本把数据变成接口"的首选。
小结：PostgREST 的价值在于把权限和语义下沉到数据库，用视图和 RLS 控制暴露面，零业务代码即可交付标准 REST 接口。对小微企业，它是连接既有数据与前端工具之间最轻的那座桥。