-
Notifications
You must be signed in to change notification settings - Fork 292
Description
In some specs, fields like firstName, lastName, email, phone, summary, location, websites, and profiles are all nested under a bio object. While nesting can be useful for grouping, in this case it creates unnecessary complexity:
Developers need to check for bio existence before accessing fields.
Simple operations (like updating or querying email) require deeper object traversal.
Error handling becomes more cumbersome with deeply nested optional fields.
Proposed Change:
Move all the fields currently inside bio to top-level keys in the user object. Example:
{
"firstName": "Faizan",
"lastName": "Techcore",
"email": "faizan@techcore.com",
"phone": "+971768544",
"summary": "Full-stack developer and AI enthusiast",
"location": "Dubai, UAE",
"websites": ["https://www.faizantechcore.com"],
"profiles": [
{"platform": "GitHub", "url": "https://github.com/faizantechcore"},
{"platform": "LinkedIn", "url": "https://www.linkedin.com/in/faizantechcore"}
]
}
Benefits:
Easier for developers—no need for nested if-statements.
Simpler CRUD operations (create, read, update, delete).
Cleaner API responses, especially for front-end consumption.
Better alignment with examples like GitHub’s API, which uses flat, top-level keys:
https://api.github.com/users/rxl
Conclusion:
Flattening the structure makes the spec more intuitive and reduces potential errors without losing clarity. bio can still exist as a readable string summary, but structured data like email, phone, websites, etc., should be top-level fields.