[DEFECT] Legacy /api/content/ read endpoint silently ignores the depth query parameter

Problem Statement

The legacy Content API read endpoint accepts depth only as a path segment. Passing it as a query parameter is silently ignored: the response returns successfully with zero relationship fields, no error, and no warning.

ContentResource.getContent is declared as @GET @Path("/{params:.*}") (dotCMS/src/main/java/com/dotcms/rest/ContentResource.java:786) and parses its options out of the catch-all path segment, so it never inspects query parameters. The endpoint is not deprecated — the @Deprecated annotations in that class are on the lock / canLock / unlock / multipart-PUT methods, not on the content GET.

This is easy to hit because the newer endpoint behaves differently: /api/v1/content/{id} does honour ?depth=N. So the same-looking parameter works on one endpoint and is silently dropped on the other. A developer moving between the two, or following an example for the wrong one, gets an empty relationship set and no indication why.

Compounding this, /api/v1/content/{id} declares @DefaultValue("-1") @QueryParam("depth") and gates hydration behind if (-1 != depth), so omitting depth there also returns no relationship fields at all — again silently. A caller who simply forgets the parameter sees the same symptom as a caller who passed it in the wrong form.

Impact: contributed to a customer investigation where relationship data appeared to come and go between page loads, because different requests behind the same page used different endpoint and parameter forms.

Steps to Reproduce

Video not applicable — response shape issue, reproducible with three requests.

1. Create two related content types with a relationship field populated on at least one contentlet.
2. Call the legacy endpoint with depth as a query parameter:
   GET /api/content/id/{identifier}?depth=3
   Actual: HTTP 200, and the response contains no relationship fields at all.
3. Call the same legacy endpoint with depth as a path segment:
   GET /api/content/query/+identifier:{identifier}%20+live:true/depth/3/type/json
   Actual: HTTP 200 with relationship fields hydrated as expected.
4. For contrast, call the v1 endpoint with the query parameter:
   GET /api/v1/content/{identifier}?depth=3
   Actual: HTTP 200 with relationship fields hydrated — the query parameter is honoured here.
5. Call the v1 endpoint with no depth at all:
   GET /api/v1/content/{identifier}
   Actual: HTTP 200 with no relationship fields, silently.

Expected: either the legacy endpoint honours ?depth=N as well, or an unsupported/ignored parameter produces a clear response — a warning, an error, or documented behaviour — rather than a successful response that quietly omits all related content.

Acceptance Criteria

• depth passed as a query parameter to the legacy /api/content/ read endpoint is either honoured or rejected with a clear message — it must not be silently ignored.
• Behaviour is consistent and documented across /api/content/ and /api/v1/content/, including the fact that /api/v1/content/{id} returns no relationships when depth is omitted.
• Documentation states, for each endpoint, how depth must be supplied and what the default is.
• Test coverage asserting that a depth query parameter on the legacy endpoint does not silently yield an unhydrated response.

dotCMS Version

Reproduced on 26.08.19-04 (Evergreen, Cloud). Present on main.

Severity

Low - Minor issue or cosmetic

Links

• Freshdesk ticket #39249
• Filed alongside the relationship-traversal defect from the same investigation (see the linked ticket); tracked separately because it is a different code path with a different fix.

Start with ContentResource.getContent in dotCMS/src/main/java/com/dotcms/rest/ContentResource.java:786 and compare its path parsing with the v1 endpoint's depth handling. Reproduce the listed legacy and v1 requests, then add regression coverage and update endpoint documentation so depth behavior, defaults, and unsupported query usage are explicit and no longer silently omit relationships.