I work with pedagogies, teach, write curricula, coach, manage, mentor, consult, speak publicly, polemicize, and sometimes work as a full-stack web developer, architect, ontologist, and more.
That's is a very good point that I should have heeded. From my experience HATEOAS implemented REST only tells you about subsequent actions doesn't it? If you need to understand parameters and available actions in a human readable way, then GraphQL is a practical developer friendly system due to it's strong opinions.
I work with pedagogies, teach, write curricula, coach, manage, mentor, consult, speak publicly, polemicize, and sometimes work as a full-stack web developer, architect, ontologist, and more.
GraphQL certainly has its strengths (I've been using it for years now). But most of the people who bash REST have never actually implemented it correctly and don't understand how flexible it can be. Partly, I think, this is because everyone wants a shortcut, like Swagger. I read Roy's thesis twenty years ago and have been trying to do REST correctly ever since, but I get a lot of pushback from other devs who think it's too much work.
One place I worked at set up a team to rewrite their REST interface (a big enterprise). After almost a year, they had little to show for it because the team met once a week and spent all their time arguing. They even had an expert consultant on the team who explained how to do it, but they of course rejected most of what he said. Ironically, at the same time they were adamant that we couldn't implement GraphQL.
Having used HTTP based message enqueueing for a long time (basically RPC) we added a RESTish (my new term for what you are describing :]) and a GraphQL interface to our back end data platform. In doing this I've realised that GQL can represent almost anything as an API, which I couldn't really "see" before. If you can jump through the hoops once it really can be used to auto-scaffold, it has clear error messages and a bunch of intellisense logic for IDEs. I'm sold on it for our purpose which is a configurable set of document types where the GQL schema is generated based on the configuration - so there's new stuff to learn regularly.
I'm most impressed by the way we can represent relational data in the schema and therefore in the responses.
I work with pedagogies, teach, write curricula, coach, manage, mentor, consult, speak publicly, polemicize, and sometimes work as a full-stack web developer, architect, ontologist, and more.
With HATEOAS you have discoverability. Without HATEOS, technically you do not have REST.
That's is a very good point that I should have heeded. From my experience HATEOAS implemented REST only tells you about subsequent actions doesn't it? If you need to understand parameters and available actions in a human readable way, then GraphQL is a practical developer friendly system due to it's strong opinions.
GraphQL certainly has its strengths (I've been using it for years now). But most of the people who bash REST have never actually implemented it correctly and don't understand how flexible it can be. Partly, I think, this is because everyone wants a shortcut, like Swagger. I read Roy's thesis twenty years ago and have been trying to do REST correctly ever since, but I get a lot of pushback from other devs who think it's too much work.
One place I worked at set up a team to rewrite their REST interface (a big enterprise). After almost a year, they had little to show for it because the team met once a week and spent all their time arguing. They even had an expert consultant on the team who explained how to do it, but they of course rejected most of what he said. Ironically, at the same time they were adamant that we couldn't implement GraphQL.
I guess we could always go back to RPC...
Having used HTTP based message enqueueing for a long time (basically RPC) we added a RESTish (my new term for what you are describing :]) and a GraphQL interface to our back end data platform. In doing this I've realised that GQL can represent almost anything as an API, which I couldn't really "see" before. If you can jump through the hoops once it really can be used to auto-scaffold, it has clear error messages and a bunch of intellisense logic for IDEs. I'm sold on it for our purpose which is a configurable set of document types where the GQL schema is generated based on the configuration - so there's new stuff to learn regularly.
I'm most impressed by the way we can represent relational data in the schema and therefore in the responses.
Sounds like GraphQL is a good choice for your use case.