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? On June 28, 2018 at 4:09:26 AM, Julian Reschke (julian.resc...@gmx.de) wrote: On 2018-06-27 12:22, Bertrand Delacretaz wrote: > On Wed, Jun 27, 2018 at 9:43 AM Julian Reschke <julian.resc...@gmx.de> wrote: >> ...Is the feature really tied to HTTP(s)? I don't think so. And if a future >> platform used a different protocol, the API wouldn't really need to change... > > +1, this is probably more about URIs than HTTP URLs. > > -Bertrand Well, switching into pedantic mode, ... The term "URL" is not the issue here. Even if it wasn't an HTTP(s) URL, it would still need to be a locator-typed URI for the functionality to work. Best regards, Julian
