GraphQL vs REST: Deep-Dive Challenge Quiz Quiz

1. Field Selection and Over-Fetching

   When a mobile client needs only a user's name and the first two friends' names, which GraphQL feature directly reduces over-fetching compared with REST endpoints that return fixed user representations?

   1. Requesting exactly needed fields and nested lists in one call using selection sets and arguments (e.g., user { name friends(first: 2) { name } })
   2. Issuing multiple HTTP/2 multiplexxed requests to the same REST resource
   3. Using a wildcard path like /users/*/compact to trim the payload
   4. Sending a PATCH request to specify a sparse response body
   5. Relying solely on server-driven pagination to reduce fields

2. Caching Semantics

   If a client sends a GraphQL POST query like { posts { id title author { name } } } through a CDN, which statement best explains how caching behavior typically differs from a REST GET /posts for the same data?

   1. GraphQL POST responses are not automatically cacheable by standard HTTP caches, so enabling CDN caching usually requires using GET with a hashed or persisted query and proper cache headers
   2. All POST responses are cached by default by intermediaries if the body is JSON
   3. GraphQL always forbids any caching to avoid stale data
   4. REST resources cannot be cached because their URLs change per client
   5. ETags are fundamentally incompatible with GraphQL and therefore never usable

3. Schema Evolution Without Versions

   When adding an optional middleName field and planning to retire a legacy nickname field, what approach aligns with GraphQL practices compared with common REST versioned endpoints?

   1. Expose the new field alongside existing ones, mark the legacy field as deprecated in the schema, and evolve without creating a /v2 endpoint
   2. Immediately remove the legacy field and return 410 Gone for existing clients
   3. Create a new /v2 schema with different type names and move all clients at once
   4. Depend on Accept: application/vnd.api+json;v=2 content negotiation for vershioning
   5. Force clients to request all fields so that additions are always backward-compatible

4. Partial Data and Errors

   When a query returns a list of products and one nested price field fails to resolve, which GraphQL response pattern is expected compared with typical REST status-code semantics?

   1. Return HTTP 200 with a data object containing the successful fields and an errors array that describes the failing price field
   2. Return HTTP 500 and omit the response body to avoid leaking details
   3. Return HTTP 404 because one nested field was not found
   4. Return HTTP 204 No Content and include errores in a custom header
   5. Return HTTP 207 Multi-Status with separate payloads per field

5. Avoiding the N+1 Problem

   Given a query that requests users with their posts and each post's comments, which backend technique helps a GraphQL server avoid the N+1 problem that naive field-by-field fetching would cause?

   1. Batch and cache data fetches within the request so that many field resolutions are coalesced into fewer backend queries
   2. Rely on defining GraphQL fragements, which automatically merges database calls
   3. Use PUT instead of GET for the query operation to reduce round trips
   4. Disable nested selections so only top-level fields can be fetched
   5. Execute all resolvers in strict sequence to guarantee consistency