[Sean-Der]

I have to disagree. The most painful APIs I have had to work with are ones that try to abstract things away, and fail. They usually create bad abstractions (don't full understand what they are trying to expose) or they don't expose enough and I waste time trying to extend them.

There is no way to know what information clients will need in the future, so it is better to not try and guess. I have no problems with a chatty client.

A good example of this is the Google APIs. Sure when you open up the godoc for the google-api-clients it seems needlessly verbose, but I have found the patterns sane and much better than making another layer of pointless abstraction.

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