If you read the article you'd know that this is about using OpenAPI Overlays and other use cases where JSONPath is literally a requirement. I think you just read the first paragraph then wrote a few about how its bad.
More and more parts of the API ecosystem require JSONPath, and just saying "you should write code instead" doesn't actually help anyone write OpenAPI Overlays, so whats the point?
The standard was developed because its being used by so many people in so many ways with so many different implementations that a standard was required to align them all, so im not sure the "nobody is really using it" argument holds much weight.
tl;dr: maybe you want OData, JSON-API, or one of the many other standards or practices that solve this simple problem as their super-set of functionality on top of the networking principles of REST.
Using GraphQL for this alone is rather nuclear, as you gain a lot with GraphQL but lose other stuff.
> But since they are already brainwashed from PHP use, it prevents them from seeing the value of doing thing the proper way, and might see the process as contrived. This is the most dangerous aspect of using PHP. It blocks your learning and understanding. It pulls you down and keep it there.
After 10 years of writing PHP I took a look at Python. I was confused for about 10 minutes, until I read about lists and dictionaries and saw they were different things.
Who are these people who are just trying to write other languages without looking at the "getting started with data structures" page in the guide, or reading a single book?
And why is learning something flexible and easy before learning something more advanced a problem?
> So I request every one who is passionate about programming and wants a career in programming to keep away from the php language and community as much as possible.
I was writing PHP for a living for a decade. I did a bit of Ruby along the way because it's all the same and who cares. I was then invited to CTO at a tech startup in NY, giving me a visa and moving me from the UK.
I replaced their shittily built Rails API with a PHP one which was 3x faster, did 10x more and was actually tested properly. Very handy.
Now I work for another company, Ride.com. We're building an API in Rails and it feels just like the one I built in PHP using Laravel. Almost identical.
This comapny got me a visa known as "The Alien of Extraordinary Ability" in which my PHP code was used as the basis of my skills.
All of this leads me to think: What the fuck are you talking about.
1. Languages rarely matter.
2. PHP is just fine.
3. PHP will not fuck up your career.
4. PHP will not ruin your ability to learn new languages.
5. You are an actual idiot.
Stop preaching ignorance and get on with writing software.
They sure do. I've written clients for services that have been autogenned from a database like this, and experienced pain repeatedly because every change they make breaks their API.
At least this product realises that and attempts to deal with versioning. Unfortunately that way is by pushing the complexity into the database.
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.
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.
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.
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.
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..
I also believe that creating a CRUD RESTful API directly on top of your database schema is a very bad idea because of the potential impedance mismatch.
PHP is just a tool that makes it very easy to create quick websites using logic directly in html. I totally agree that this is a bad practice and should be avoided. This is why it attracted a lot of script kiddies at its beginning.
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.
It truly blows my mind that any further explanation would be required.
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.
API developer and authur who handcrafts via middleware (PHP) hates framework that automatically generates APIs from database features? Quelle f'ing surprise.
A developer who has been invited into the USA twice because of his skills at building complex APIs for complex companies suggests that automated solutions are a cancer on the API building industry?
> 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.
More and more parts of the API ecosystem require JSONPath, and just saying "you should write code instead" doesn't actually help anyone write OpenAPI Overlays, so whats the point?