Description
Attachment content returned from:
$contentApi->children(
$page,
Content::CONTENT_TYPE_ATTACHMENT,
);
is successfully hydrated as a ContentAttachment.
The Confluence API response also contains a download endpoint:
```json
"_links": {
"self": "https://.../rest/api/content/att884637698",
"download": "/rest/api/content/883982338/child/attachment/att884637698/download"
}
Currently the client exposes the self URL via AbstractContent::getUrl(), but the download URL is discarded during hydration.
This means consumers can retrieve attachment metadata, but cannot download the attachment itself without re-querying the Confluence REST API.
Proposed solution
Extend ContentAttachment with a dedicated download URL property.
For example:
public function getDownloadUrl(): ?string;
public function setDownloadUrl(?string $downloadUrl): self;
Hydrate the value from:
$data['_links']['download']
Notes
- This intentionally does not change the behaviour of AbstractContent::getUrl(), which correctly represents the resource's self endpoint.
- The proposal simply preserves additional attachment-specific information already returned by the API.
Description
Attachment content returned from:
Currently the client exposes the self URL via AbstractContent::getUrl(), but the download URL is discarded during hydration.
This means consumers can retrieve attachment metadata, but cannot download the attachment itself without re-querying the Confluence REST API.
Proposed solution
Extend ContentAttachment with a dedicated download URL property.
For example:
Hydrate the value from:
$data['_links']['download']Notes