> It’s the #1 reason why graphql is so popular. You only fetch what you want.

It's certainly one of the main sales points for graphql. On the flip side, I've never been frustrated by getting too many fields back from an API. I suppose if I was developing exclusively in extremely bandwidth limited contexts where getting back only 2 fields rather than 50 actually made a difference, I might care. It just seems like such a non-issue to solve/talk about in almost every other context.

It's likely more of an issue if you're wanting to fetch lots of nested data in one request, but only a few specific fields of what could be an extremely large object, like say the just the names and profile picture URIs for a large set of users that have interacted with the object your fetching. This is particularly relevant to social media, such as Facebook.

For the cases we've hit, it made sense to do a more specialized endpoint (or media type) than to create a universal way to let clients pick that fields they want.

This works way nicer with caches and APIs where the URI is a first class citizen.

> On the flip side, I've never been frustrated by getting too many fields back from an API

A pretty common use-case I have is needing to support these three things :

- A “big object” list screen (where retrieving the whole objects would make the query return megabytes off data)

- A “big object” details screen (where I need the full object)

- Programmatically getting many big objects

With GraphQL it involves writing one (or two) straightforward queries, while with REST it would require more thought or code.

> With GraphQL it involves writing one (or two) straightforward queries, while with REST it would require more thought or code.

Aren't you just pushing the work to the back end? The GraphQL resolver is a new layer of complexity while with REST is more straightforward.

Yes, but you don’t have that many network round trips.

Maybe, maybe not.

If there is some sequence that is used a lot and you've determined it to be a bottleneck, you can write a custom endpoint for it.

You could simply use HAL with embedded resources in JSON. Not sure how the client side feels about that though

It's simpler if it's normalized like with JSONAPI, but all of the apps I've worked on use an E(T)L process where the transformation step normalizes the data before saving it to our cache.

I was frustrated immensely due to that.

I could fetch the objects in bulk request.. except they didn't have the field i needed when fetched in bulk. So i had to do bulk fetch, where each object was pretty big and then fetch them again individually.

If that service supported graphql i could easily just grab what i need, without hammering the poor already over-utilized server.

This kind of issues prop up constantly especially if you use on-perm hosting.

I like having the option to select fields as an optimization, but the main reason i dont like graphql is because it forces me to select fields from the beginning. Most of the time I dont know what the fields are until i look at the data in context. In general, I dont like anything that forces me to rely on documentation.

This can really screw up your cache hit ratio.

We could support "fields" query parameter in REST API to get only necessary attributes. Eg. ?fields=f1,f2,f3 etc.

OData adds this kind of functionality to REST APIs, in a standardised way. It can do filtering, pagination, sorting etc (your backend data provider of course needs to support these operations).

You can do it with query params. Its not enforced or consistent because not everything that serves data can parse the data.

You could throw static json blobs on S3 as a rest API but selections would not be supported.

I wish S3 supported filters on predefined content - eg. json. That would be a killer feature

With Amazon S3 Select, you can use simple structured query language (SQL) statements to filter the contents of Amazon S3 objects and retrieve just the subset of data that you need. By using Amazon S3 Select to filter this data, you can reduce the amount of data that Amazon S3 transfers, which reduces the cost and latency to retrieve this data.

Amazon S3 Select works on objects stored in CSV, JSON, or Apache Parquet format. It also works with objects that are compressed with GZIP or BZIP2 (for CSV and JSON objects only), and server-side encrypted objects. You can specify the format of the results as either CSV or JSON, and you can determine how the records in the result are delimited.

You pass SQL expressions to Amazon S3 in the request. Amazon S3 Select supports a subset of SQL. For more information about the SQL elements that are supported by Amazon S3 Select, see SQL reference for Amazon S3 Select and S3 Glacier Select.

You can perform SQL queries using AWS SDKs, the SELECT Object Content REST API, the AWS Command Line Interface (AWS CLI), or the Amazon S3 console. The Amazon S3 console limits the amount of data returned to 40 MB. To retrieve more data, use the AWS CLI or the API.

https://aws.amazon.com/blogs/aws/s3-glacier-select/

https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-gla...

Did you ever check out odata? It seems that's exactly what you want