Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Before an API uses a JSON request, check more than whether the text parses. A JSON parser catches malformed syntax; schema validation checks whether the parsed data fits the endpoint’s contract; application logic checks whether it makes sense for the operation. Formatting only changes how valid data is represented as text—it does not validate it.
How to validate JSON before an API uses it
Use this sequence on the server side for incoming requests. The order matters: resource limits must apply before parsing, and later checks should operate on the same parsed representation that the application will use.
- Check the HTTP request. Confirm that the endpoint accepts a body and that its
Content-Typeis supported. For JSON, the standard media type isapplication/json. Reject unsupported media types according to the API contract. - Set resource limits before reading and parsing. Limit request-body size before buffering it, and configure parser limits such as maximum nesting depth. Consider implementation limits for string length and numeric range or precision. Schema validation happens too late to protect a parser from an oversized or deeply nested body.
- Parse with a maintained JSON parser. Treat syntax errors as invalid input and stop before application logic. Do not use JavaScript
evalor another eval-like mechanism: input treated as executable code can create a security risk. - Validate the parsed structure. Use a framework validator or schema to define allowed types, required fields, nested-object rules, array item and length constraints, and whether unrecognized fields are allowed. Configure each policy explicitly.
- Apply business rules. Check conditions that depend on the operation’s meaning, such as whether fields are mutually consistent or a requested quantity is acceptable. A schema can check structure, but it cannot decide every domain rule.
- Pass the validated representation onward. Avoid decoding the request again or letting downstream components reinterpret it differently. Repeated or inconsistent decoding can undermine earlier checks.
RFC 8259, the IETF’s December 2017 JSON standard, describes the parser’s role this way: “A JSON parser transforms a JSON text into another representation.” Parsing establishes that the text conforms to JSON grammar; it does not establish that the resulting value satisfies your endpoint’s requirements.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11What syntax, schema validation, and business validation each check
Syntax parsing
JSON text represents a value. Valid values include objects, arrays, strings, numbers, booleans, and null. A parser checks whether the text follows JSON grammar and produces a data representation. A syntactically valid value may still be the wrong type or shape for an endpoint.
#1 Best Overall
Schema validation
A schema describes structural expectations. For an object, state which properties are required and what should happen to properties the schema does not list. Naming a property in a schema does not necessarily make it required, and unknown properties are not necessarily rejected by default. Nested objects and array elements may need their own constraints.
Business validation
Application checks address meaning and state: for example, whether two supplied values are compatible for this operation or whether a requested amount is allowed. Keep these checks distinct from syntax and structure so errors can be handled at the right layer.
Rank #2
How to format JSON for an API
Formatting selects a textual representation of structured data. JSON permits insignificant whitespace around structural characters, so both compact and indented JSON can be valid. Generate JSON with a serializer rather than assembling JSON text by hand.
- Compact output: typically useful for transport because it omits optional indentation and line breaks.
- Pretty output: useful for logs, debugging, or human review because indentation and line breaks make the structure easier to inspect.
Either form must obey JSON grammar. Pretty-printing does not repair invalid data or prove that a request meets the API contract. A parse-and-serialize cycle also need not preserve the original bytes: implementations may normalize number or string representations, and object member order should not determine application behavior.
Quick Recap
Rank #4
Interoperability and security checks
- Handle duplicate object names deliberately. RFC 8259 notes that implementations behave differently when names repeat: a parser may keep the last value, reject the object, or expose duplicate pairs. Reject duplicates when the parser supports it, or define and test a consistent policy across the systems that exchange the data.
- Do not depend on object-property order. Consumers should use member names and values, not the order in which properties happen to appear.
- Use UTF-8 for exchanged JSON. RFC 8259 requires UTF-8 for JSON exchanged outside a closed ecosystem and says generators must not add a byte-order mark to JSON sent over a network.
- Understand schema format checks. A schema’s email or URL format assertion is generally a syntactic check, not proof that an address or referenced resource exists. Check real-world state separately when the application requires it.
- Return safe, useful errors. Tell callers which input condition failed without exposing stack traces or unnecessary internal implementation details.
Common mistakes to avoid
- Accepting a body because it parses, without checking its shape or business meaning.
- Applying size or nesting checks only after parsing.
- Assuming a declared schema property is automatically required or that undeclared properties are automatically forbidden.
- Treating whitespace changes as validation, or expecting a serializer to preserve the exact original JSON text.
- Parsing JSON with an eval-like function, or decoding the same body repeatedly in different layers.
- Assuming a format assertion proves that an email address or URL exists.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
