public static IValidationBuilder AddMaxExecutionDepthRule(
this IValidationBuilder builder,
int maxAllowedExecutionDepth)
{
return(builder
.AddValidationRule((s, o) => new MaxExecutionDepthVisitor(o))
.SetAllowedExecutionDepth(maxAllowedExecutionDepth));
}
public static IValidationBuilder AddMaxComplexityRule(
this IValidationBuilder builder,
int maxAllowedComplexity)
{
return(builder
.AddValidationRule((s, o) => new MaxComplexityVisitor(o))
.SetAllowedComplexity(maxAllowedComplexity));
}
/// <summary>
/// GraphQL servers define what directives they support.
/// For each usage of a directive, the directive must be available
/// on that server.
///
/// http://spec.graphql.org/June2018/#sec-Directives-Are-Defined
///
/// AND
///
/// GraphQL servers define what directives they support and where they
/// support them.
///
/// For each usage of a directive, the directive must be used in a
/// location that the server has declared support for.
///
/// http://spec.graphql.org/June2018/#sec-Directives-Are-In-Valid-Locations
///
/// AND
///
/// Directives are used to describe some metadata or behavioral change on
/// the definition they apply to.
///
/// When more than one directive of the
/// same name is used, the expected metadata or behavior becomes ambiguous,
/// therefore only one of each directive is allowed per location.
///
/// http://spec.graphql.org/draft/#sec-Directives-Are-Unique-Per-Location
/// </summary>
public static IValidationBuilder AddDirectiveRules(
this IValidationBuilder builder)
{
return(builder.AddValidationRule <DirectiveVisitor>());
}
/// <summary>
/// Every argument provided to a field or directive must be defined
/// in the set of possible arguments of that field or directive.
///
/// http://spec.graphql.org/June2018/#sec-Argument-Names
///
/// AND
///
/// Fields and directives treat arguments as a mapping of argument name
/// to value.
///
/// More than one argument with the same name in an argument set
/// is ambiguous and invalid.
///
/// http://spec.graphql.org/June2018/#sec-Argument-Uniqueness
///
/// AND
///
/// Arguments can be required. An argument is required if the argument
/// type is non‐null and does not have a default value. Otherwise,
/// the argument is optional.
///
/// http://spec.graphql.org/June2018/#sec-Required-Arguments
/// </summary>
public static IValidationBuilder AddArgumentRules(
this IValidationBuilder builder)
{
return(builder.AddValidationRule <ArgumentVisitor>());
}
/// <summary>
/// GraphQL allows a short‐hand form for defining query operations
/// when only that one operation exists in the document.
///
/// http://spec.graphql.org/June2018/#sec-Lone-Anonymous-Operation
///
/// AND
///
/// Each named operation definition must be unique within a document
/// when referred to by its name.
///
/// http://spec.graphql.org/June2018/#sec-Operation-Name-Uniqueness
///
/// AND
///
/// Subscription operations must have exactly one root field.
///
/// http://spec.graphql.org/June2018/#sec-Single-root-field
/// </summary>
public static IValidationBuilder AddOperationRules(
this IValidationBuilder builder)
{
return(builder.AddValidationRule <OperationVisitor>());
}
/// <summary>
/// If any operation defines more than one variable with the same name,
/// it is ambiguous and invalid. It is invalid even if the type of the
/// duplicate variable is the same.
///
/// http://spec.graphql.org/June2018/#sec-Validation.Variables
///
/// AND
///
/// Variables can only be input types. Objects,
/// unions, and interfaces cannot be used as inputs.
///
/// http://spec.graphql.org/June2018/#sec-Variables-Are-Input-Types
///
/// AND
///
/// All variables defined by an operation must be used in that operation
/// or a fragment transitively included by that operation.
///
/// Unused variables cause a validation error.
///
/// http://spec.graphql.org/June2018/#sec-All-Variables-Used
///
/// AND
///
/// Variables are scoped on a per‐operation basis. That means that
/// any variable used within the context of an operation must be defined
/// at the top level of that operation
///
/// http://spec.graphql.org/June2018/#sec-All-Variable-Uses-Defined
///
/// AND
///
/// Variable usages must be compatible with the arguments
/// they are passed to.
///
/// Validation failures occur when variables are used in the context
/// of types that are complete mismatches, or if a nullable type in a
/// variable is passed to a non‐null argument type.
///
/// http://spec.graphql.org/June2018/#sec-All-Variable-Usages-are-Allowed
/// </summary>
public static IValidationBuilder AddVariableRules(
this IValidationBuilder builder)
{
return(builder.AddValidationRule <VariableVisitor>());
}
/// <summary>
/// The target field of a field selection must be defined on the scoped
/// type of the selection set. There are no limitations on alias names.
///
/// http://spec.graphql.org/June2018/#sec-Field-Selections-on-Objects-Interfaces-and-Unions-Types
///
/// AND
///
/// Field selections on scalars or enums are never allowed,
/// because they are the leaf nodes of any GraphQL query.
///
/// Conversely the leaf field selections of GraphQL queries
/// must be of type scalar or enum. Leaf selections on objects,
/// interfaces, and unions without subfields are disallowed.
///
/// http://spec.graphql.org/June2018/#sec-Leaf-Field-Selections
/// </summary>
public static IValidationBuilder AddFieldRules(
this IValidationBuilder builder)
{
return(builder.AddValidationRule <FieldVisitor>());
}
