Closed kerolasa closed 1 year ago
Hi @kerolasa it would have been also an interesting approach with using variables. In the end the spec authors decided rather to use fixed named parameters on template apply. See 4.2.2. for details.
If you think this part of specification is still confusing let's work on a rephrase.
I see. Let me write how I now understand sharedServiceName and sharedProviderName work. Rest of this comment refers only to Service with intention same rules apply to both.
Default is to display serviceName
from template that must be static string, that is, not a variable.
When sharedServiceName
is true the template sharedName
is can be replaced using providers apply parameter. This would look something like the following.
{urlAPI}/v2/domainTemplates/providers/{providerId}/services/{serviceId}/apply?sharedName=exampleName
A sharedServiceName
enabled template without optional apply parameter will default to the template serviceName
.
Assuming the above sounds right feel free to close this issue. But if I have misunderstood please add a comment that explains how things play together. And in the later case -- yes, the spec most definitely needs more verbosity and/or rewording how sharing a name is expected to take effect.
Generally correct.
The query parameter in the example would be serviceName
rather than sharedName
, as per the table in 4.2.2.
The sharedServiceName has explanation:
"This flag indicates that the template allows the caller to pass in additional information for the serviceName. This information should augment the display of the serviceName from the template."
Does that mean the value of serviceName can be a template when sharedServiceName is true? And the opposite way around, value is false the serviceName must not use template. Or am I completely mistaking what is meant with allows the caller to pass in additional information.