[steve-rodrigue]

Creating an API directly on top of your database schema brings the problem of impedance mismatch in all the client applications built directly on top of your new API.

However, if you create an Endpoint (Objects) based RESTful API on top of your database schema and then use this new API in all your client's applications, you will have the problem of impedance mismatch in only 1 application: your REST API.

For more information related to impedance mismatch: http://en.wikipedia.org/wiki/Object-relational_impedance_mis...

It might be a good idea to create a "build and forget" application on top of a RESTful API built directly on top of a database schema. I would probably use it for a movie website, since movie sites are normally built to promote the movie and forgotten after.

However, building client applications you need to maintain on a longer term, on top of a RESTful API built directly on top of a database schema is a terrible idea. It will get harder to maintain as the database schema evolves and the amount of client applications grows.

[rpedela]

I don't see how this tool automatically introduces impedance mismatch? It is certainly possible depending on how the application is written, but I don't see how it must happen?

[steve-rodrigue]

Impedance mismatch happens often when directly mapping table's data to an object. When working with an API that match perfectly a database table, the user will have 2 choices (inside his client's applications):

1) Building an object from the data received from a REST call (which is the same as mapping a table's data to an object).

2) Create 1 or multiple REST calls to the API, transform the data and creates an object.

The chances that #1 happens is far greater... since #2 is normally done when building an endpoint (Object) RESTful API. So, if you would do #2, it might be a better idea to create an endpoint API and comsume it in all your client's applications...

If you do #1, your client's applications will be exposed to impedance mismatch.

[sinkasapa]

I don't see how these problems from the object oriented paradigm necessarily translate to this tool. It assumes a lot about how one plans to use their REST API.

[e12e]

Why would you map your REST API to tables and not views (or stored procedures)? When would you ever want to have tables interfacing with your application unless you're doing something absurdly under-/de-normalized?

[zapov]

You can avoid this in Postgres which supports objects and collections.

So... no. O/R impedence doesn't apply to an ORDBMS