Keep embed params out of subresource self links

[milanmajchrak]

References

• Related to dataquest-dev/dspace-customers#862 and Fix the causes of the REST self link console warnings dspace-angular#1415 (the frontend side)
• Upstream: DSpace/DSpace issue 8577 — open since 2022-11-09, good first issue, never fixed
• Upstream PR 3105 (issue 3062) fixed exactly this, but only for the collection endpoints
• No REST Contract PR needed — no endpoint or field changes, and the contract already states the self link should not carry parameters that don't affect the resource

Description

Subresource list endpoints put the request's embed parameters into their own self link, so
/items/<uuid>/bundles?embed=primaryBitstream reports a self link that isn't the resource that was
requested. Collection and search endpoints already exclude them; this does the same for subresources.

Instructions for Reviewers

RestResourceController.findRelInternal builds the self link from the raw query string:

String querystring = request.getQueryString();
link = linkTo(this.getClass(), apiCategory, model).slash(uuid)
    .slash(subpath + '?' + querystring).withSelfRel();

The collection (findAllInternal) and search (executeSearchMethods) paths instead go through
getEncodedParameterStringFromRequestParams, which drops embed and embed.*. That helper was
added by PR 3105 to fix issue 3062 — but it was never wired into the subresource path, which is why
issue 8577 is still open.

List of changes in this PR:

• Added removeEmbedParamsFromQueryString, and used it in findRelInternal. It filters out only
  embed and embed.* and passes every other parameter through verbatim — no re-encoding, so a
  client's own percent-encoding is preserved.
• Added BundleRestRepositoryIT.getItemBundlesSelfLinkHasNoEmbedParams, asserting the self link
  keeps size=10 and no longer contains embed.

How to test:

GET /api/core/items/<uuid>/bundles?embed=primaryBitstream&size=10

Before: "self": ".../bundles?embed=primaryBitstream&size=10"
After: "self": ".../bundles?size=10"

A real DSpace 9.1 instance returns this for an item page load, which is what the frontend reports as
"The response for … has the self link … These don't match":

.../bundles?embed=primaryBitstream&embed=bitstreams/format&embed.size=bitstreams=5

Worth a reviewer's attention: when every parameter was an embed one, the self link now has no query
string at all — that is the intended result, and it is what the collection endpoints already do.

Checklist

• My PR is created against the main branch of code — no: fork PR, base is dtq-dev. The
  same change applies to upstream main; a patch is prepared separately for a human to submit.
• My PR is small in size (2 files, one 12-line private method plus a 1-line call site change).
• My PR follows all coding best practices based on the Code Conventions Guide.
• My PR passes Checkstyle validation (mvn -pl dspace-server-webapp checkstyle:check, exit 0).
• My PR includes Javadoc for the new private method.
• My PR passes all tests and includes new/updated Unit or Integration Tests — the IT is
  written, but it has not been executed: DSpace's test harness needs a configured dspace.dir,
  which this machine doesn't have (dspace-api tests fail the same way on an untouched checkout).
  The filter logic itself was verified in jshell against the real query strings, including that
  embedded=x is not stripped. Someone with a working test environment should run the IT.
• My PR includes details on how to test it.
• If my PR includes new libraries/dependencies — none.
• If my PR modifies REST API endpoints — it doesn't add or remove any; it changes the value of an
  existing self link, which the REST Contract already describes as not carrying parameters that
  can't affect the resource.

[milanmajchrak]

Nedávať zatiaľ merge — našiel som regresiu

EmbeddedPageHeader._link() stavia všetky stránkovacie linky z toho istého self buildera:

private Href _link(final Sort sort, Integer page, int size) {
    UriComponentsBuilder uriComp = self.cloneBuilder();

Takže keď z self linku vypadne embed, vypadne aj z first/next/prev/last.

Väčšine frontendu to nevadí — napr. FileSectionComponent.getNextPage() si request prestaví sám cez data service, ktorá followLink znovu pridá. Ale browse-by stránka nasleduje tie linky priamo:

// browse-by-metadata-page.component.ts
goNext() { ... this.browseService.getNextBrowseItems(items); }
// browse.service.ts
return this.hrefOnlyDataService.findListByHref<Item>(items.payload.next);

A /discover/browses/title/items sa volá s embed=thumbnail (overené v prehliadači proti DSpace 9.1). Po tejto zmene by druhá a ďalšie strany browse-by prišli o náhľady.

Poznámka: kolekcie a search týmto trpia už dnes — ide o rovnaký builder — takže táto zmena len rozširuje existujúce upstream správanie. To ale z regresie nerobí nie-regresiu.

Odporúčanie: nemergovať. Warning už rieši FE strana (dataquest-dev/dspace-angular#1415) bez tohto rizika. Ak by sme chceli self link opraviť poriadne, treba oddeliť builder pre self od builderu pre stránkovacie linky v EmbeddedPageHeader — to je ale zásah do zdieľaného stránkovacieho kódu všetkých endpointov, čiže väčšie riziko, nie menšie.

[milanmajchrak]

Closing: the frontend fix (dataquest-dev/dspace-angular#1415) removes the warning without this regression risk. See the previous comment on EmbeddedPageHeader pagination links.