# Repair a Django Post-Creation Endpoint and Its React Contract A Django and React blogging application has a bug: users complete all required fields but cannot create and publish a post. Repair `POST /api/posts/` so it reads request data, validates required fields, associates the new post with the user identified by the `X-User-Id` header, persists the post, and returns HTTP `201` with the response shape expected by the React application. The request body contains: ```json { "title": "string", "content": "string", "excerpt": "string", "category": "string", "tags": ["string"], "readTime": 5 } ``` `title`, `content`, and `category` are required. Optional fields receive documented defaults. The response must include `_id` and a nested `author`, and the saved post must appear under “My Posts.” Two supplied tests verify the expected response values and structure and verify database persistence. ### Constraints & Assumptions - The supplied models, serializers, URL routing, React client, and tests define exact field names and defaults. - A missing or unknown user header must return a client error instead of creating an ownerless post. - The exercise header identifies the acting user, but a production design still requires trusted authentication rather than accepting an arbitrary caller-provided identity. - The response and database write must represent the same committed post. ### Clarifying Questions to Ask - Which serializer or schema currently defines the API response and optional defaults? - Is `readTime` stored under that exact name or translated to a model field? - How does “My Posts” filter ownership, publication state, and author identity? - Which status and error shape do existing clients expect for missing fields or an unknown user? - Are tags separate records, a JSON field, or a relation requiring transactional handling? ### What a Strong Answer Covers - Reproduction through the supplied tests and tracing the React payload, Django route, view, serializer, model, and “My Posts” query. - Validation from `request.data` with explicit required fields and type-safe defaults for excerpt, tags, and read time. - Resolution of the user, clear failure for missing or unknown identity, and acknowledgement of the trust boundary. - One transactional creation path that persists the author relationship and tag data before returning `201`. - Response serialization that maps the stored identifier to `_id` and includes the nested author shape required by the frontend. - Verification that the ownership field used on create is the same field used by “My Posts.” - Focused failure tests and avoidance of broad exception handling or a response assembled independently of the saved object. ### Follow-up Questions 1. The database row exists, but “My Posts” remains empty. Which ownership and publication fields would you compare? 2. Why is returning the submitted JSON with a generated `_id` weaker than serializing the committed model instance? 3. How should tag creation behave if one tag is invalid after the post row has been inserted? 4. What authentication change would be required before trusting this endpoint in production? 5. Which test distinguishes a defaulted empty tag list from a missing required category?