Mock Nested Blog Post API Response

Nested Blog Post Response

Blog post APIs typically return deeply nested structures that combine the post content with related entities like the author, tags, and comments. This mock demonstrates how to represent these relationships in a single API response.

Schema Structure

{
  "id": "uuid",
  "title": "string",
  "slug": "string",
  "body": "string",
  "status": "enum(draft,published,archived)",
  "author": {
    "id": "uuid",
    "name": "string",
    "email": "email",
    "avatarUrl": "url"
  },
  "tags": [
    { "id": "uuid", "name": "string", "slug": "string" }
  ],
  "comments": [
    {
      "id": "uuid",
      "body": "string",
      "author": { "id": "uuid", "name": "string" },
      "createdAt": "date"
    }
  ],
  "publishedAt": "date (nullable)",
  "createdAt": "date"
}

Embedding vs References

This response uses embedding (inline nested objects) rather than references (IDs only). Embedding is suitable when:

• The nested data is always needed when viewing the parent
• The nested objects are small
• You want to reduce the number of API calls

For large or optional relationships, consider returning just IDs and using separate endpoints or includes/sideloading patterns.

Array of Objects Pattern

The tags and comments fields demonstrate the array-of-objects pattern. Each array item is a complete object with its own id. This pattern is common for one-to-many and many-to-many relationships.

Nullable publishedAt

The publishedAt field is nullable because draft posts have not been published yet. This tests how your UI differentiates between draft and published content.