[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..