On 2018-07-18 04:09, Matt Ryan wrote:
I’ve changed the code to use URIs instead of URLs.
Regarding the HTTP-specific naming: The latest iteration of the API
requires some HTTP-specific elements that need to be able to be set on
download URIs. More specifically, these are elements that the
implementation directs a service provider to set headers to certain
values on responses to requests for the signed download URIs. These are
things like being able to set the response Content-Type or
Content-Disposition header for example. (This is discussed further in
OAK-7637.)
As a result I do think it is evolving to be a bit HTTP-specific.
Are there specific concerns with the naming as it is?
I would say that these are not *necessarily* HTTP-specific, and thus we
should try to define them in a generic way.
Best regards, Julian
