GraphQL is an open-source query language and data manipulation language that you can use to deliver structured API content to clients. This ensures clients receive exactly the content they request while preventing both over-fetching and under-fetching of data. GraphQL has no native query caching to avoid refetching resources, and standard HTTP caching will not work for a GraphQL API.
If your registered API uses GraphQL schemas to describe API content, you can configure GraphQL settings in the API Definitions configuration to let edge servers identify GraphQL queries and set specific instructions for caching GraphQL responses.
On the GraphQL
settings page, you can define the query parameter that clients should use to
include GraphQL queries in GET and POST requests. For POST requests, you can also define the
JSON body parameter that indicates a location of a GraphQL query. When an edge server receives
a request, it identifies the GraphQL query in the parameters that you previously defined. This
is applicable for the
application/json content type. If a request’s content type is
application/graphql, the entire
request body is instantly treated as a GraphQL query.
The default behavior for GraphQL queries is to return partial data if only a portion of a request fails. Because of this, errors are not simply indicated by status codes as they are with a RESTful API. Instead, error details are part of a successful response payload. For example, a 200 status code response may include in payload errors related to some portion of the requested data. You can tell edge servers to look for such errors in a GraphQL response payload and determine whether to cache response payload in case of an error.
The following limitations apply for all GraphQL requests:
- When caching GraphQL queries, the maximum allowed size of a query is 4096 bytes.
- When caching GraphQL queries, the maximum allowed nesting depth is 10 levels.
- When processing payload error handling, the maximum allowed size for a response payload is 1024 bytes.