week 9 - web services Flashcards
What is JSON Schema, and how does it help with data validation?
Definition:
A vocabulary to annotate and validate JSON data.
Format:
Written in JSON with one element defining rules for data.
Uses:
Automating tests.
Ensuring high-quality client-submitted data.
Combining data from different sources.
Example: Patient Appointment Validation
Scenario: A healthcare system for booking patient appointments.
JSON Schema: (Defines data rules)
{
“$schema”: “http://json-schema.org/draft-07/schema”,
“type”: “object”,
“properties”: {
“patientName”: { “type”: “string” },
“age”: { “type”: “integer”, “minimum”: 0 },
“appointmentDate”: { “type”: “string”, “format”: “date” },
“email”: { “type”: “string”, “format”: “email” },
“symptoms”: { “type”: “array”, “items”: { “type”: “string” } }
},
“required”: [“patientName”, “appointmentDate”, “email”],
“additionalProperties”: false
}
Key Rules Defined:
patientName: Must be a string (e.g., “John Doe”).
age: Must be a non-negative integer (e.g., 25).
appointmentDate: Must follow a valid date format (e.g., “2024-12-01”).
email: Must follow a valid email format (e.g., “john.doe@example.com”).
symptoms: Must be an array of strings (e.g., [“fever”, “cough”]).
How This Relates to Use Cases:
Automating Tests:
Invalid data, e.g., age: -5, is immediately flagged.
Guaranteeing Data Quality:
Missing email or incorrect appointmentDate (e.g., 2024/13/01) is rejected.
Combining Data Sources:
Clinics sending data in different formats are made compatible using this schema.
How does items in array work
REALLY GOOD FLASHCARD
JSON Schema: Understanding items Validation
Basic Rules for items
When items is an array of schemas (tuple validation), it works by position matching:
jsonCopySchema:
{
“type”: “array”,
“items”: [
{ “type”: “number” },
{ “type”: “string” },
{ “enum”: [“red”, “blue”] }
]
}
Key Points:
Position Matching:
First element in validation(test) array matches against first type in items
Second element matches against second type
And so on…
Default Behavior:
You don’t need all positions filled
Additional items are allowed by default
Additional items can be any type
Examples:
jsonCopyVALID arrays:
[1, “hello”, “red”] // Full match
[1, “hello”] // Partial match ok
[1] // Just first element ok
[1, “hello”, “red”, true] // Extra items ok (any type)
[1, “hello”, “red”, 42, {}] // Multiple extra items ok
INVALID arrays:
[“1”, “hello”, “red”] // Wrong type in first position
[1, 2, “red”] // Wrong type in second position
[1, “hello”, “green”] // Not in enum for third position
basic types in json schema / json
string.
number.
integer.
object.
array.
boolean.
null.
What does JSON Schema NOT define or validate, and can you provide an example?
Meaning of Data:
JSON Schema does not explain the semantic meaning or purpose of the data—it only ensures that the structure and types are correct.
Example:
JSON Schema:
json
Copy code
{
“type”: “object”,
“properties”: {
“age”: { “type”: “integer” },
“diagnosis”: { “type”: “string” }
},
“required”: [“age”, “diagnosis”]
}
Valid JSON Data:
json
Copy code
{
“age”: 200,
“diagnosis”: “Hypertension”
}
The schema only checks that “age” is an integer and “diagnosis” is a string.
It does not check if “age”: 200 is a biologically realistic age or if “Hypertension” is a valid diagnosis—it assumes the user provides meaningful data.
What are the key responsibilities of JSON Schema, and how do they work with examples?
Example JSON:
json
{
“patientData”: {
“name”: “Alice Smith”,
“age”: 30,
“diagnosis”: “Diabetes”
}
}
Responsibilities of JSON Schema:
Defines Data Types:
“name” must be a string (e.g., “Alice Smith”).
“age” must be an integer (e.g., 30).
“diagnosis” must be a string (e.g., “Diabetes”).
Defines Structure:
The JSON must have a top-level key “patientData”.
Inside “patientData”, the keys “name”, “age”, and “diagnosis” must follow a specific structure.
Defines Required Fields:
“name”, “age”, and “diagnosis” are required fields.
If “age” or “diagnosis” is missing, the JSON is invalid.
What is the default behavior of JSON Schema when the “required” keyword is not used, and how does it compare to when it is explicitly defined?
Example 1: No “required” Keyword (Default Behavior)
Schema:
Since “required” is not specified, all fields (“name”, “age”, “diagnosis”) are optional by default.
json
{
“type”: “object”,
“properties”: {
“name”: { “type”: “string” },
“age”: { “type”: “integer” },
“diagnosis”: { “type”: “string” }
}
}
Valid JSON (Even if some fields are missing):
json
Copy code
{
“name”: “Alice Smith”
}
HOWEVER:
Example 2: Using “required” Keyword
Schema:
json
Copy code
{
“type”: “object”,
“properties”: {
“name”: { “type”: “string” },
“age”: { “type”: “integer” },
“diagnosis”: { “type”: “string” }
},
“required”: [“name”, “age”]
}
NAME AND AGE required ie :
Invalid JSON (If “age” is missing):
json
{
“name”: “Alice Smith”
}
This JSON is invalid because “age” is marked as required.
Both “name” and “age” must be present for the JSON to be valid.
What’s revealed to the public: implementation or interface?
Interface is revealed to the public (it shows how to interact with the service).
Implementation remains hidden (it handles the internal workings of the service).
Look at week 9 web services last slide
very good table on
SOAP VS REST
fdnpaspfjsdp
SEPERATOR QUICK FLASHCARDS
JSON SCHEMA DOES WHAT
. defines data types
. defines the required fields
. defines structure
.DOESN NOT CHECK SEMANTIC MEANING TO SEE IF LOGICAL
