Valid inputs can mean very different things
A JSON document may be an object, array or simple value. Therefore null is valid even when your contract requires an object. Some numbers exceed JavaScript’s integer precision, and repeated property names are not interpreted consistently by all parsers.
| Demonstration input | Syntax reading | Remaining check |
|---|---|---|
| {"ok":true} | Valid. | Does the value meet the contract? |
| {"ok":true,} | Invalid: trailing comma. | Handle the error explicitly. |
| null | Valid. | Does the contract allow null? |
| {"id":9007199254740993} | Valid number, precision risk in JavaScript. | Use a string for this identifier. |
| {"a":1,"a":2} | Repeated names: nonportable interpretation. | Define and enforce a rejection policy. |
Check every reception stage
- Use a maintained JSON parser, never eval. Check HTTP status, expected content type, size limits and explicit handling of absent or malformed bodies.
- Then validate the contract: root type, required fields, permitted values and the difference between missing, null and zero. Preserve long identifiers as strings when the contract specifies this.
- Set depth and resource limits, a duplicate-name policy and error handling. Do not insert received strings into HTML or queries without appropriate protection.
Keep errors useful without exposing data
Test partial responses, version changes and Unicode. Log minimal context instead of secrets or complete bodies. A decoding failure should neither become an empty result presented as success nor silently stop an entire processing chain.
Primary references
Log JSON API errors without leaking payloads
A JSON body may carry identifiers, secrets or personal data. Diagnosis often needs event type, route, outcome, correlation identifier and a non-sensitive failure detail rather than the full payload.
- Classify fields and mask those not needed for diagnosis.
- Test parsing and schema failures with synthetic values.
- Check that error logs and exports do not copy full payloads.
Primary reference: ACSC and partners — Event logging and threat detection. Related method: read the practical guide.
A cache must distinguish JSON representations
Fictional example: these inputs describe no customer or observed result.
Two route versions return different schemas, and a client receives a cached response for the other version.
- Test version selection and representation dimensions, then compare cache keys with client validation.
- Separate representations and handle incompatibility explicitly. Parseable JSON may still violate the expected contract.
Primary reference: IETF — RFC 9111, HTTP Caching. Related method: read the practical guide.
Validate continuation fields too
Parsing paginated responses must preserve identifiers and continuation information. Parseable JSON may contain a short page or unexpected token; check those states against the contract before concluding collection traversal is complete.
- Test short pages with continuation and responses missing expected completion fields.
- Preserve identifier types and values without conversions that alter them.
- Detect repeated tokens, truncated responses and recovery after batch storage.
Acceptance case to reproduce
Fictional example: these inputs describe no customer or observed result.
View case inputs
{
"page_1_ids": [
"A",
"B"
],
"page_2_ids": [
"B",
"C"
],
"next_cursor": "c2",
"empty_page_has_next_cursor": true
}Expected decision
B repeats. Check identities and continue while a next cursor exists, even after an empty page.
Verification procedure
- Fix filters, stable order and object identity.
- Test duplicates and an empty page with a next cursor.
- Keep identifiers, cursors and the actual end condition. Reconcile received objects and unique identifiers; flag repeated cursors without treating an empty page with a continuation as collection completion.
Primary reference: Google AIP-158 — Pagination. Related method: read the practical guide.