A schema is a formal outline of permitted data: its structure, fields, types, rules, and constraints. Teams define it before development so consumers and providers work toward the same shape, often using JSON Schema. section 3.3
A schema describes what data may look like, but not how consumers use it or which fields they actually depend on. Contract testing adds those consumer interactions and detects breaking changes as the schema evolves. section 3.3
GraphQL movie schema
A GraphQL schema defines a Movie with id, name, and year, then exposes movie and movies queries. Resolvers separately define how those queries obtain data. A query requesting an undeclared rating field fails. section 7.1 section 7.2.1
Listing 3.1 Pact contract example
"consumer": { #1
"name": "Web"
},
"provider": { #1
"name": "API"
},
"interactions": [ #2
{
"description": "GET user token",
"providerState": "user authentication setup",
"request": {
"method": "GET",
"path": "/token/1234",
"headers": {
"Accept": "application/json, text/plain, */*"
}
},
"response": {
"status": 200,
"headers": {
"Content-Type": "application/json"
},
"body": {
"token": "bearer xxx"
},
"matchingRules": { #3
"$.body.token": {
"match": "type"
}
}
}
}
],
"metadata": {
"pactSpecification": {
"version": "4.0"
}
}
}
Inspect a Pact contract that combines request and response data with consumer and provider names, interaction details, matching rules, and specification metadata. section 3.3
