Schema definitions in Rest API - Time & Space Complexity
When working with schema definitions in REST APIs, it's important to understand how the time to process schemas changes as they grow.
We want to know how the execution time grows when the schema has more fields or nested objects.
Analyze the time complexity of the following schema validation code snippet.
function validateSchema(data, schema) {
for (const field in schema) {
if (typeof schema[field] === 'object' && schema[field] !== null) {
validateSchema(data[field], schema[field]);
} else {
if (typeof data[field] !== schema[field]) {
throw new Error('Invalid type');
}
}
}
}
This code checks if the data matches the schema by going through each field and validating types, including nested objects.
- Primary operation: Looping over each field in the schema object.
- How many times: Once for each field, including recursively for nested objects.
As the number of fields in the schema grows, the function checks each one, including nested fields.
| Input Size (fields in schema) | Approx. Operations |
|---|---|
| 10 | About 10 checks |
| 100 | About 100 checks |
| 1000 | About 1000 checks |
Pattern observation: The number of operations grows roughly in direct proportion to the number of fields.
Time Complexity: O(n)
This means the time to validate grows linearly with the number of fields in the schema.
[X] Wrong: "The validation time stays the same no matter how big the schema is."
[OK] Correct: Each field must be checked, so more fields mean more work and longer time.
Understanding how schema validation time grows helps you explain API performance and design better data checks.
"What if the schema included arrays of objects? How would the time complexity change?"
Practice
schema definition in a REST API?Solution
Step 1: Understand what schema definitions do
Schema definitions specify how data should look and what rules it must follow in an API.Step 2: Match purpose with options
Only To describe the structure and rules of the data exchanged correctly states that schemas describe data structure and rules.Final Answer:
To describe the structure and rules of the data exchanged -> Option DQuick Check:
Schema = Data structure and rules [OK]
- Confusing schema with security features
- Thinking schema speeds up API
- Assuming schema handles errors
name in an OpenAPI schema?Solution
Step 1: Recall OpenAPI property syntax
Properties are defined as key-value pairs with a type inside an object, e.g.,name: { type: 'string' }.Step 2: Compare options
Only name: { type: 'string' } matches the correct syntax for defining a string property.Final Answer:
name: { type: 'string' } -> Option BQuick Check:
Property syntax = key: { type: 'string' } [OK]
- Writing type outside an object
- Using plain string without type key
- Confusing property name with type
age property?
components:
schemas:
User:
type: object
properties:
age:
type: integer
minimum: 0
Solution
Step 1: Read the schema property definition
Theageproperty is defined withtype: integerand a minimum value of 0.Step 2: Identify the data type
The type clearly statesinteger, meaning whole numbers only.Final Answer:
integer -> Option AQuick Check:
age type = integer [OK]
- Assuming age is string by default
- Confusing integer with boolean
- Ignoring the type key
{
"type": "object",
"properties": {
"id": { "type": "integer" },
"email": { "type": "string", "format": "email" },
"active": "boolean"
},
"required": ["id", "email"]
}Solution
Step 1: Check property definitions
Each property must be an object with a "type" key. "active" is given as a string "boolean" instead of an object.Step 2: Validate other parts
"id" type integer is correct, "required" does not need "active", and commas are correctly placed.Final Answer:
"active" property should be an object with a type key -> Option CQuick Check:
Property format = object with type key [OK]
- Writing property types as strings directly
- Forgetting to wrap property details in objects
- Assuming required means all properties
username (string) and roles (array of strings). Which schema snippet correctly represents this?Solution
Step 1: Understand the data structure
The response is an object with a "users" property that is an array of user objects.Step 2: Check each user object schema
Each user has "username" as string and "roles" as an array of strings, so nested arrays and objects are needed.Step 3: Match with options
Only type: object properties: users: type: array items: type: object properties: username: type: string roles: type: array items: type: string correctly nests arrays and objects with proper types and keys.Final Answer:
type: object properties: users: type: array items: type: object properties: username: type: string roles: type: array items: type: string -> Option AQuick Check:
Nested arrays and objects = type: object properties: users: type: array items: type: object properties: username: type: string roles: type: array items: type: string [OK]
- Writing array items as plain strings
- Confusing object and array types
- Missing nested items key for arrays
Ready to prove it?
Pass the test and this pattern moves unknown
