Sparse fieldsets
Trim payloads to the exact attributes a client needs. Meridian endpoints accept afields[type]query parameter that filters response shape per resource type, cutting bandwidth and parse cost without forcing a custom endpoint for every consumer.
1.Request only what you render
A dashboard tile that shows a user's display name and avatar does not need the full profile. Pass a comma-separated list of attribute keys per resource type. Unlisted attributes are dropped from the response before serialization, so latency wins start at the database layer.
GET /v1/users/usr_8421
?fields[users]=display_name,avatar_url
200 OK
{
"id": "usr_8421",
"type": "users",
"attributes": {
"display_name": "Ada Lovelace",
"avatar_url": "https://cdn.meridian.dev/u/8421.webp"
}
}2.Combine with included relationships
Sparse fieldsets compose withinclude. Request a primary resource plus its related records, then prune both shapes in the same call. Each type gets its own filter, so a single round trip returns a graph trimmed to exactly what the view renders.
3.Cache keys and pitfalls
The full query string (includingfields[*]) is part of the cache key. Stable ordering of comma-separated keys is the cheapest way to lift hit rates. Never rely on sparse responses for authorization decisions, the server still evaluates permissions against the full record before pruning.