DEV Community

Discussion on: Rest v/s GraphQL !

Collapse
 
alexanderjanke profile image
Alex Janke

In REST because of its tendency to pull all the data it brings a huge amount of data which is unnecessary to the client !

Isn't this just bad API design though?

Collapse
 
fjones profile image
FJones

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.

Collapse
 
chasm profile image
Charles F. Munat

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.

Collapse
 
alexanderjanke profile image
Alex Janke

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