[steve-rodrigue]

A good API is an API that abstract its database schema and expose designed Endpoints (Objects) to its clients.

By exposing Objects instead of your schema, your API has less chance to be updated as frequently, since its internal data storage is separated from its public API.

For the same reason, it is a bad practice to have multiple applications reading and writing data directly in your database. Building an Endpoint based API on top of your database and sharing this API across your clients is a better option.

Building an API directly on top of a database schema also brings the problem of impedance mismatch in all your client's applications: http://en.wikipedia.org/wiki/Object-relational_impedance_mis...

The problems here have nothing to do with the fact that the API might be chatty.

[joevandyk]

Views are the mechanism this uses to separate the representation from the underlying data model. You don't expose your schema directly with this tool, you expose views that can stay the same when the data model changes.

[steve-rodrigue]

Even if it uses views, it still binds your data storage to your RESTful API. If you use such an application, it won't be possible to move some data to other data storage, such as Redis, to normalize some data, for example, without modifying all your client's applications.

If you create an endpoint (object) based API, you will be able to modify it the way you like, and if you change your data storage, your client's applications won't even know that you modified your internal databases.

EDIT Please keep in mind that my comments are only valid if you are building an API that you will have to maintain on a long term basis. Otherwise, this project is great... like I said in another comment, I'll probably use it for simple "build and forget" projects.

[fit2rule]

I think you have not adequately asked yourself the question: "why does my database change so much?" and "why does this matter?", because in reality - for such projects as this tool is targeted, which I would mostly estimate is for quick prototyping needs, this is immensely useful.

Here, I see it looking a bit like this:

    $ make db
    $ make onboard_data
    $ make generate_rest
    $ make client_bindings
    $ make clients
    $ make tests && make release

I see nothing wrong with a properly managed project perpetuating this set of commands through multiple versions..