Just today I read about postgrest[1], REST-like API for postgresql.
While it is not REST by what this cookbook says (it uses JSON), it provides very different view at how API should work.[2]
Postgrest versions the API using HTTP accept header. It provides "pagination" not using XML attributes, but using HTTP range headers, as the standard allows to specify partial content in items, not just in bytes. The author also suggest that deeply nested URLs are a bad idea, because most data (like relational data) is actually flat.
It might provide interesting "second opinion" to what this cookbook says. It doesn't say anything about transactions,
>HTTP range headers, as the standard allows to specify partial content in items, not just in bytes
When doing HTTP Range requests, you'd use HEAD to get the complete length first. If your range requests are in items, is it still in spec to specify Content-Length in items too? I'd think that would break some clients.
While it is not REST by what this cookbook says (it uses JSON), it provides very different view at how API should work.[2]
Postgrest versions the API using HTTP accept header. It provides "pagination" not using XML attributes, but using HTTP range headers, as the standard allows to specify partial content in items, not just in bytes. The author also suggest that deeply nested URLs are a bad idea, because most data (like relational data) is actually flat.
It might provide interesting "second opinion" to what this cookbook says. It doesn't say anything about transactions,
[1]: https://github.com/begriffs/postgrest [2]: http://begriffs.com/posts/2014-12-30-intro-to-postgrest.html