Field Selection

One reason teams reach for GraphQL is over-fetching: an endpoint returns 30 fields when the client needs 3. REST can offer the same control with two simple query parameters.

Sparse fieldsets

Let the client list the fields it wants with ?fields=:

GET /articles?fields=id,title

The server returns only those keys. This shrinks payloads for mobile clients and list views, and documents intent. Always include the resource’s identifier even if not requested, so responses stay addressable.

By default, link to related resources rather than embedding them. When a client wants them inline, let it opt in with ?expand=:

GET /articles/42?expand=author

Without expand, author is a reference ({ "id": 7, "href": "/users/7" }); with it, the author object is embedded. This keeps the default response small while avoiding an extra round trip when the client genuinely needs the related data.

Projecting fields in code

JavaScript

function project(obj, fields) {
  if (!fields) return obj;
  const wanted = new Set(['id', ...fields.split(',')]); // always keep id
  return Object.fromEntries(Object.entries(obj).filter(([k]) => wanted.has(k)));
}

const article = { id: 42, title: 'Hello', body: 'long...', views: 1200, authorId: 7 };
console.log(project(article, 'title,views'));

Advantages (Field Selection)	Trade-offs
Smaller payload — saves bandwidth on mobile networks	Server must parse the `fields` parameter and filter the response
Less over-fetching — pull only what you need	Response shape varies by request — caching gets harder
Less serialization time on the server	Harder to document — the response shape isn’t fixed
High client flexibility	For heavy flexibility needs, GraphQL may fit better

Common mistakes

Inconsistent field selection Symptom:

?fields=name,email on one endpoint, ?select=name,email on another
Developers have to remember a different parameter name per endpoint
Use fields (or select) consistently across the whole API

No fallback when a field doesn’t exist Symptom:

?fields=name,nonExistentField — the server returns 500, or silently omits the field
The client can’t tell whether a missing field is null or doesn’t exist
Return 400 for an unknown field, or ignore it gracefully and document the behavior

💡 Real-world examples

Google APIs:

?fields=items(id,title,description) — select fields down to nested levels

Cuts response size for bandwidth-constrained mobile clients

LinkedIn API:

Projection parameter: ?projection=(id,localizedName,localizedHeadline)

Trims a 50+ field response down to just what’s needed

Sources: Google APIs performance tips, LinkedIn Profile API

Field Selection

Sparse fieldsets

Expanding related resources

Projecting fields in code

Common mistakes