Simplify JSON Validation and Boost Robustness

When exchanging data between applications, web services, or APIs, even the slightest structural error can break everything. That’s why JSON data validation is an essential step in many scenarios, including API integration, data import/export, application configuration, and communication between microservices. 4D 21 R3 is not just an update to Draft 2020-12, it is a full alignment with modern web and API standards. JSON validations become more powerful, more expressive, and fully compatible with today’s tools.

HDI: Json Validate

What is a schema?

A JSON schema lets you precisely describe the expected structure of a document: data types, required fields, allowed values, and formats (email, URL, etc.).

Thanks to this schema, you can guarantee the quality and reliability of your data exchanges without manually writing verification code. If the received JSON does not comply with the defined rules, 4D tells you exactly where and why the validation fails.

This saves considerable time, increases the security of your applications, and provides a solid foundation for designing robust interfaces or reliable web services.

4D offers the JSON Validate command to compare a JSON object against a schema compliant with the JSON Schema standard. With 4D 21 R3, this command takes a major leap; it now supports the most recent versions of the standard (Draft 2020-12), offering greater flexibility, new keywords (const, if/then/else, unevaluatedProperties, …), native 4D date validation, and better interoperability with modern tools.

Example: using conditional rules

The new JSON Schema standard introduces powerful conditional rules, allowing you to encode part of your business logic directly into the schema, something that was cumbersome or impossible with Draft-04.

Let’s take a classic example: validating a payment depending on the selected method. Depending on the payment method:

• if it’s a credit card, “cardNumber” and “expiryDate” must be provided,
• if it’s a bank transfer, “iban” and “bic” are required,
• otherwise (for example, cash payments), none of these fields are required.

With Draft-04, you had to implement all these checks manually in your 4D code. The schema could only define types, basic constraints, and required fields, but it couldn’t express conditional logic like “if paymentMethod = credit_card then require cardNumber and expiryDate”.

Draft-2020-12 changes everything. You can now define these conditional rules directly in the JSON Schema. Here’s a practical example:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Order Schema",
  "type": "object",
  "properties": {
    "orderId": { "type": "integer" },
    "customer": { "type": "string" },
    "amount": { "type": "number", "minimum": 0 },
    "paymentMethod": {
      "type": "string",
      "enum": ["credit_card", "bank_transfer", "cash"]
    },
    "cardNumber": { "type": "string", "pattern": "^[0-9]{16}$" },
    "expiryDate": { "type": "string", "pattern": "^(0[1-9]|1[0-2])/[0-9]{2}$" },
    "iban": { "type": "string" },
    "bic": { "type": "string" }
  },
  "required": ["orderId", "customer", "amount", "paymentMethod"],

  "if": { "properties": { "paymentMethod": { "const": "credit_card" } } },
  "then": { "required": ["cardNumber", "expiryDate"] },
  "else": {
    "if": { "properties": { "paymentMethod": { "const": "bank_transfer" } } },
    "then": { "required": ["iban", "bic"] }
  }
}

This schema combines:

• regular expressions (pattern) to control the format of numbers;
• conditional rules (if/then/else) to adapt required fields depending on the payment type.

Then, on the 4D side, simply validate the response:

var $response; $schema; $result : Object
$response := JSON Parse($json; *)
$schema := JSON Parse($jsonSchema)
$result := JSON Validate($response; $schema)

If ($result.success)
  // your treatment
Else
  // manage errors
End if

Thanks to built-in validation, your 4D code stays simple: there’s no need to manually test conditions based on the payment method.

The schema becomes a true functional specification that can be shared across the backend team, the front-end, or even third-party partners.

Compatibility

Each JSON schema specifies the standard to use through the $schema attribute.

In 4D, only two JSON Schema parsers are supported:

• Draft-04
• Draft 2020-12

The selected parser is determined exclusively by the value of the $schema property in the JSON Schema document.

For example:

• To use Draft-04:

"$schema": "http://json-schema.org/draft-04/schema#"

• To use Draft 2020-12:

"$schema": "https://json-schema.org/draft/2020-12/schema"

This means your existing schemas based on Draft-04 will continue to work perfectly, while still giving you the freedom to adopt the new version at your own pace.

If the $schema attribute is not specified, 4D defaults to Draft-04. However, we strongly recommend specifying the standard to use. If you share your schema to validate responses from your REST API, or to explain the response format to an AI, they need to know which version of the schema you are using.

Key Takeaways

With 4D 21 R3, the JSON Validate command is aligned with modern JSON validation standards, making it possible to validate data coming from AI APIs or any other web service. You benefit from:

• support for the latest JSON Schema standard,
• more powerful new keywords,
• improved compatibility with industry tools,
• while maintaining compatibility with your existing schemas.

By combining JSON Validate with API calls in your 4D projects, you strengthen the reliability of your AI integrations and secure your data flows, without any additional effort. This update positions 4D among the platforms capable of speaking the language of modern APIs, micro-services, and generative AI.