让 PostgreSQL 提供 RESTful API 服务：PostgREST
PostgREST能够从现有的PostgreSQL数据库提供一个完整RESTful API服务。它提供了一个更清洁，更符合标准，更快的API比你从头开始写。
示例：postgrest.herokuapp.com | Watch Video
Try making requests to the live demo server with an HTTP client such as postman. The structure of the demo database is defined by begriffs/postgrest-example. You can use it as inspiration for test-driven server migrations in your own projects.
用法
Download the binary (OS X / Ubuntu) and invoke like so:
postgrest --db-host localhost --db-port 5432 \ --db-name my_db --db-user postgres \ --db-pass foobar --db-pool 200 \ --anonymous postgres --secure \ --port 3000
Performance
TLDR; subsecond response times for up to 2000 requests/sec on Heroku free tier. (see the load test)
If you're used to servers written in interpreted languages (or named after precious gems), prepare to be pleasantly surprised by PostgREST performance.
Three factors contribute to the speed. First the server is written in Haskell using the Warp HTTP server (aka a compiled language with lightweight threads). Next it delegates as much calculation as possible to the database including
- Serializing JSON responses directly in SQL
- Data validation
- Authorization
- Combined row counting and retrieval
- Data post in single command (returning *)
Finally it uses the database efficiently with the Hasql library by
- Reusing prepared statements
- Keeping a pool of db connections
- Using the Postgres binary protocol
- Being stateless to allow horizontal scaling
Ultimately the server (when load balanced) is constrained by database performance. This may make it inappropriate for very large traffic load. To learn more about scaling with Heroku and Amazon RDS see the performance guide.
Other optimizations are possible, and some are outlined in the Future Features.
Security
PostgREST handles authentication (HTTP Basic over SSL) and delegates authorization to the role information defined in the database. This ensures there is a single declarative source of truth for security. When dealing with the database the server assumes the identity of the currently authenticated user, and for the duration of the connection cannot do anything the user themselves couldn't.
Postgres 9.5 will soon support true row-level security. In the meantime what isn't yet implemented can be simulated with triggers and security-barrier views. Because the possible queries to the database are limited to certain templates using leakproof functions, the trigger workaround does not compromise row-level security.
For example security patterns see the security guide.
Versioning
A robust long-lived API needs the freedom to exist in multiple versions. PostgREST supports versioning through HTTP content negotiation. Requests for a certain version translate into switching which database schema to search for tables. PostgreSQL schema search paths allow tables from earlier versions to be reused verbatim in later versions.
To learn more, see the guide to versioning.
Self-documention
Rather than writing and maintaining separate docs yourself let the API explain its own affordances using HTTP. All PostgREST endpoints respond to the OPTIONS verb and explain what they support as well as the data format of their JSON payload.
The number of rows returned by an endpoint is reported by - and limited with - range headers. More about that.
There are more opportunities for self-documentation listed in Future Features.
Data Integrity
Rather than relying on an Object Relational Mapper and custom imperative coding, this system requires you put declarative constraints directly into your database. Hence no application can corrupt your data (including your API server).
The PostgREST exposes HTTP interface with safeguards to prevent surprises, such as enforcing idempotent PUT requests, and
