Postgrest deviates from some REST URL conventions that REST users are familiar with. As an example, one very common convention gives each item a distinct path with the 'id' (the primary key of some table, typically) as the last path element: /some_path/123. Notice that the 'key' column name is implied and simple (not compound).
Postgrest does not adopt this convention. This decision is not arbitrary, however. Postgrest is conceptually a function that computes a REST API for a PostgreSQL database, and tables in a PostgreSQL can (for better or worse) have compound primary keys, which do not map well to a simple URL path. So Postgrest uses a more general URL syntax. The equivalent of the above is: /some_path?id=eq.123.
Postgrest represents some novel thinking about the use of certain HTTP verbs as well. A lot of this is discussed in the Postrest introduction video here: http://postgrest.com/
> Postgrest deviates from some REST URL conventions that REST users are familiar with.
Those are common API conventions, but they have nothing to do with REST; REST only requires unique URI's for resources, it has nothing to say about the format of those URI's. The Postgres version does not deviate from REST, it deviates from a popular API pattern, that's all.
If you're actually doing REST, the URI convention is irrelevant since you won't be constructing URI's to being with, but following the URI's given to you by previous entry points. Actual REST requires you follow links, not construct them. So having well defined URI conventions like above actually harm the REST API be encouraging API clients to construct links manually rather than use the links given to them and it hurts the API by not allowing the server to change the URI structure over time because clients become bound to a particular format. Those conventions are harmful under the principles of REST as they encourage tight coupling and prevent change. URI's are not supposed to matter for a reason, REST is supposed to be hypermedia, i.e. follow links, don't build them.
REST specifically rejects the need for URL conventions because HATEOAS. If URL conventions matter -- i.e., if resource identifiers are communicated out-of-band rather than client and server being decoupled by way of resource identifiers being communicated in-bamd through hypermedia -- what you are doing is not REST, but instead exactly the problem for which REST is the solution.
Postgrest does not adopt this convention. This decision is not arbitrary, however. Postgrest is conceptually a function that computes a REST API for a PostgreSQL database, and tables in a PostgreSQL can (for better or worse) have compound primary keys, which do not map well to a simple URL path. So Postgrest uses a more general URL syntax. The equivalent of the above is: /some_path?id=eq.123.
Postgrest represents some novel thinking about the use of certain HTTP verbs as well. A lot of this is discussed in the Postrest introduction video here: http://postgrest.com/