Hacker News Reader

Comment by Pxtl | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com