[
https://issues.apache.org/jira/browse/NIFIREG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16352688#comment-16352688
]
Kevin Doran commented on NIFIREG-136:
-------------------------------------
I like the idea of having the REST API supporting both names and identifiers in
resource paths, and I agree we should introduce this enhancement in a
non-breaking manner.
In terms of implementation, I'm fine with introducing something in the path to
indicate you are specifying a name. Alternatively, here are some ideas for how
to implement this so that the meaning of the url path parameter is inferred
without explicit syntax used by the client:
I've never tried it before, but I think we may be able offer this distinction
transparently to the client/user by leveraging JAX-RS support for
regex-constrained path parameter matching to "overload" the
{{/buckets/<param>}} and {{/buckets/<param>/flows/<param>}} endpoints to first
determine if the parameter is a UUID or not. I've never tried this in a case
where one regex (UUID) is a subset of another regex (e.g, name would just be
any arbitrary string presumable, or any string not-matching a UUID regex?), but
it might be worth a try.
If doing this with two regexes in the JAX-RS annotation is not possible, a
similar implementation variant would be to introduce two "explicit" endpoints
with distinguishing fields such as {{n=<string>}} or {{i=<string>}} to give the
parameter a specific meaning, and then change the logic of the existing
endpoint to determine the parameter type (UUID or not) and then map to the
correct endpoint, either through redirect or URL Path Rewriting in the
application filter chain. Clients that wanted to be explicit could use the
explicit syntax. Clients that don't care could just pass a name or UUID and I'm
fairly certain we could infer the meaning in ever case. We would have to
introduce a constraint during bucket/flow creation that the name cannot match a
UUID regex.
> Switch to unique human-friendly names for buckets and flows
> -----------------------------------------------------------
>
> Key: NIFIREG-136
> URL: https://issues.apache.org/jira/browse/NIFIREG-136
> Project: NiFi Registry
> Issue Type: Improvement
> Affects Versions: 0.1.0
> Reporter: Andrew Grande
> Priority: Major
>
> I have been playing with the Registry and using [~bende] 's early CLI to
> accomplish some automation tasks. Have had really tough times with UUIDs
> being used for buckets and flows, it introduced a lot of context switches to
> locate/save/copy/paste those when using the API.
> I would strongly suggest considering the human-friendly names and convert
> deep links to using those instead. This not only provides for an easy
> portable full URI, but also addresses compatibility issues between instances
> of the registry, as buckets & flows with the same name are guaranteed to have
> different UUIDs. A kind of copy/paste between environments.
> I never came across a unique name requirement within a tree-like structure to
> be an issue when dealing with NiFi. E.g. NiFi and NiFi Registry could
> transparently reverse-look up the UUID by extracting names from the URI. The
> goal is to have a great user experience.
> P.S.: spaces in the name in the URI could be substituted for '+' sign
> transparently, using the %20 would defeat the purpose of smooth ease-of-use.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
