Content-Disposition: attachment

[iameugenejo]

Should we define a spec for an API endpoint that responses Content-Disposition: attachment header for downloadable contents?

Or should we separate out the endpoint as a download-only service?

If the endpoint can stay with the other Hyperion conforming endpoints, can the downloaded contents be not conforming to the spec?

[ardiesaeidi]

What if you made an async endpoint that generated a large report in a background job and then dumped the file some where for the user to retrieve later on? That might make your API more performant and allow for the user to retrieve it efficiently.

For example:

POST /report
HTTP STATUS CODE: 204
RESPONSE:
{
 "@id": "/report/1",
 "id": 1
}

A client can then keep polling /report/1 until it returns a 200 and the hyperion resource.

GET /report/1
HTTP STATUS CODE: 200
RESPONSE:
{
 "@id": "/report/1",
 "id": 1,
 "url": "https://somesecurestorage.com/report/EHB3WGRs7vEqt.json"
}

[iameugenejo]

That will require a separate mechanism to ensure security of the contents. If it was served through the API, it would enforce the OAuth flow to do that, but with the download url, it has to be public or token base where the toke would expire in a few hours or so.

If you’re talking about the download url that takes OAuth token, then what’s the difference between having that separate service and have it along with other endpoints within the same domain?