Should API operation responses always include references to parent resources? I think so.

Imagine you have the getStoreEmployees operation, which gets all the employees who work in a specific store. The operation is available via an HTTP GET to /stores/{storeId}/employees/{employeeId}. The response includes employee information such as the name, role, and salary. In my opinion, it should also include a reference to the store where the employee works. It can be a full HATEOAS-style or, to simplify things, it can be a shallow reference including only the store’s ID.

Here are some advantages of this approach:

• Contextual clarity: If a resource only makes sense within the scope of a parent (such as the one between employees and stores), then reflecting that parent in the representation makes the relationship explicit and clear for clients.
• Self-descriptive representations: One of the key REST constraints (originating from Roy Fielding’s work) is that messages should be self-descriptive. Embedding parent references adds metadata about relationships.
• Navigation and linking: The parent ID facilitates linking, caching, and client logic (e.g., “which store does this employee belong to?”) without relying purely on the request URI.
• Endpoint structure: If your endpoint is /stores/{storeId}/employees/{employeeId}, it makes sense for the response to also carry storeId so that clients that drop the URI or process the payload standalone still have full context.