Bryan Bende created NIFIREG-148:
-----------------------------------
Summary: Add "export"/"import" REST end-points
Key: NIFIREG-148
URL: https://issues.apache.org/jira/browse/NIFIREG-148
Project: NiFi Registry
Issue Type: Improvement
Affects Versions: 0.1.0
Reporter: Bryan Bende
Currently if we want to do an export/import we can use the end-point to
retrieve a version of a flow which gives us the JSON representation of a
VersionedFlowSnapshot:
{code:java}
buckets/<bid>/flows<fid>/versions/<v>{code}
This end-point was not made specifically for an export operation, so it returns
metadata specific to the given registry, such as the flow and bucket info, and
a self link.
We should have end-points like:
{code:java}
buckets/<bid>/flows<fid>/versions/<v>/export
buckets/<bid>/flows<fid>/versions/latest/expor{code}
Which return a representation that is intended to be imported directly to
another registry. The representation needs to consider the following:
* Deterministic ordering - whatever the representation is, it must serialize
in a deterministic order so that comparing two exported versions of a flow
outside of the registry would let them be diff'd by standard tools. Jackson and
JAX-B both have ways of controlling the order.
* Representation - Currently the existing end-points all return JSON via
Jackson serialization of the domain model, but the FlowPersistenceProvider uses
JAX-B with an encoded version in a magic byte. So we need to decide if we
should standardize on one representation in case a git-based
FlowPersistenceProvider is implemented, we would possibly want exported flows
to look the same as what is being stored in git.
On the import side we can currently do an initial import via a two-step process
where we first create a flow and then post the first version. We should be able
to take an exported version and go right to an initial import in one step.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
