You just got an accidental downvote as I came back after bookmarking your link. Sorry.

Dang/mods: Can we please please get something to avoid accidentally downvoting good stuff on mobile phones?

Happens all the time and has been the most requested feature of all time. I like to take the charitable view and say the current design is there to let your ego explain away down votes - i.e. I am only being down voted by accident, not my post is terrible.

That feature is included with every new account!

It's especially bad on mobile, but desktop can be a problem too. I know I've misclicked a downvote on rare occasion, to my regret.

I gotta plug OpenRESTy at this point. It's based on Nginx, and it's really easy to work with. It is my go-to REST solution for PostgreSQL.

It's not going to be as easy as you make it sound - getting rid of the application tier. Think of all the goodness that the Spring framework provides, for example. Do you anticipate all the modules will be taken over by a database?

Postgrest has a very clever design. I want to see other tools going this route.

It would be kinda cool to find a way to stuff a fast HTTP server into Postgres and run it all directly from the Postgres process serving the request.

There is an nginx module for this.

People seem to dislike this because they want separate components in order to 'scale out', but honestly, having the option for most trivial applications would be extremely nice. Even more so when you consider Postgres supports routines written in non-sql programming languages.

relevant?:

https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_la...

I looked at Postgrest, and it was a little more opinionated re URLs and associations than I would have preferred.

I'm not that familiar with REST. Care to explain what you mean?

REST just mean exposing your business object via HTTP verbs. In addition to the normal Get and Post http verbs used by your browser, there's also Delete and Put. Put is effectively equivalent to an Upset command, so with Get, Put, and Delete you've got all the operations to manage an object (create/read/update/delete), with Post for special procedures.

Those also obviously correspond to the Insert/update/select/delete SQL operations.

So hooking a RESTful interface direct to your db lets JavaScript on the client talk directly to the database via an http server with no business layer in between. It's obviously a nifty workflow for the "JavaScript all the things" developer.

That said, I think restfulness is a bit of a fad tied to the popularity of javascript-everything. But it has created a limited, simple standard for http services, so that's nice.

Thanks but I was referring to what the person meant by saying that something was not like he would have preferred.

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.

I like the idea of REST as a language-agnostic datasource; adhering to conventions facilitates this.

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.

noob here .. if the database is in charge of serving rest, where does the business logic go? am i right in thinking that this would eliminate the need for a django/express?

The database stores the data, the rest API handles the business logic. Django has multiple plugins for providing a REST API, such as Tastypie. http://tastypieapi.org/ With this, django is the API. A rest API is good for when you want to share data between multiple clients (eg a website and mobile apps) and want to have more complicated business logic than the database can provide by itself.