Yes and no. The alternative is tailored endpoints, which leads to exponential maintenance growth, or an approximation of what GQL already does out of the box. Consumer-declared output structure is an excellent design for general-purpose APIs. GQL has its downsides when it comes to complex nesting, but that is more indicative of bad API design than anything.
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.
Nesting is one thing, but for limiting the columns/keys returned, it's simply a matter of passing a query string (for GETS) or a list in the headers (for POST/PUT/PATCH). All REST interfaces should be designed this way. There is no point passing back what isn't required.
You can use query strings to indicate joins, selects from nested elements, etc., too, but this might be past the point of diminishing returns -- and would start to resemble putting GraphQL in the query string. What would be the point?
So which is better depends on your data model, really.
Hmm fair enough. I was just thinking about closed source software/websites. There I can easily tailor the endpoints to my needs and know exactly what's requested. Public APIs sure are way different in that aspect though
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Yes and no. The alternative is tailored endpoints, which leads to exponential maintenance growth, or an approximation of what GQL already does out of the box. Consumer-declared output structure is an excellent design for general-purpose APIs. GQL has its downsides when it comes to complex nesting, but that is more indicative of bad API design than anything.
Nesting is one thing, but for limiting the columns/keys returned, it's simply a matter of passing a query string (for GETS) or a list in the headers (for POST/PUT/PATCH). All REST interfaces should be designed this way. There is no point passing back what isn't required.
You can use query strings to indicate joins, selects from nested elements, etc., too, but this might be past the point of diminishing returns -- and would start to resemble putting GraphQL in the query string. What would be the point?
So which is better depends on your data model, really.
Hmm fair enough. I was just thinking about closed source software/websites. There I can easily tailor the endpoints to my needs and know exactly what's requested. Public APIs sure are way different in that aspect though