Seems relevant.
Kayne West of PHP. That says it all.
Oh and I know Go, so I must be super intelligent, because only super intelligent people use Go.
On the othr hand, according to Wikipedia ( http://en.wikipedia.org/wiki/Brogrammer ) a "brogrammer" is a social programmer, normally attracted in hacking jobs at startups. Therefore, I believe PHP doesn't attract "brogrammers" since most startups do not work with PHP anymore. I believe new languages attracts more "brogrammers" than PHP.
PS: Please keep in mind that, nowadays, there are a lot of good programmers that write clean PHP code. Just have a look at the Symfony2 code source.
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.
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.
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.
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
If you want a data store that exposes your database over HTTP then use on of the billion data stores that is designed to do that. None of those are meant to be a public API, and doing this is so incredibly wreckless and short sighted I could write at least a chapter in a book about it.
Actually, I did write a chapter in a book about it.
https://leanpub.com/build-apis-you-wont-hate
A RESTful API is about so many more things than just shoving a generic CRUD interface on top of your data schema.
Am I mistaken in thinking that this project offers much more control than shoving a generic CRUD interface on top of a data schema?
Obviously, something like this would provide a great way to bootstrap a REST api for the basics you need. Sure, it may run into limits when more specificity is necessary, but that's the trap that all autogen frameworks run into.
Quelle f'ing surprise.
Normally, a REST API is formed of Endpoints (Objects), so this article should explain the problem fairly well: http://en.wikipedia.org/wiki/Object-relational_impedance_mis...