[
https://issues.apache.org/jira/browse/NIFI-7718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Weng updated NIFI-7718:
-----------------------------
Description:
We're seeing the need of NiFI REST clients in different languages, such as
Python, Go, etc, so that software can be created to control and manage NiFi
cluster and flows.
Since the RESTful API is documented in OpenAPI spec v2, a client SDK can be
generated via
[openapi-generator|https://github.com/OpenAPITools/openapi-generator]
Individual effort is seen from the community, such as:
* [https://github.com/erdrix/nigoapi]
* [https://github.com/simingweng/nifi-go-client]
* [https://github.com/Chaffelson/nipyapi]
It would be beneficial to the community to consolidate the effort and centrally
maintain the Client SDK effort for everybody to use.
Just like {{minifi}} being a sub project of NiFi, we can create sub project for
different language bindings, such as:
* apache/nifi-clients
* apache/nifi-client-go
A single repo like \{{nifi-clients}} can house all the languages that does not
requires separate repo for publishing, \{{nifi-client-go}} is an exception
because Go Module couples with its own repo.
was:
We're seeing the need of NiFI REST clients in different languages, such as
Python, Go, etc, so that software can be created to control and manage NiFi
cluster and flows.
Since the RESTful API is documented in OpenAPI spec v2, a client SDK can be
generated via
[openapi-generator|https://github.com/OpenAPITools/openapi-generator]
Individual effort is seen from the community, such as:
* [https://github.com/erdrix/nigoapi]
* [https://github.com/simingweng/nifi-go-client]
* [https://github.com/Chaffelson/nipyapi]
It would be beneficial to the community to consolidate the effort and centrally
maintain the Client SDK effort for everybody to use.
Just like \{{minifi}} being a sub project of NiFi, we can create sub project
for each language binding, such as:
* apache/nifi-client-go
* apache/nifi-client-python
A \{{repo-per-language}} approach is favored for various reasons, take
[https://github.com/kubernetes-client] as sample:
* each language has its idiomatic way to publish and share
* easier for contributor to maintain and release
* each language may require different custom templates, almost certainly
different code generation configurations
* some language has tighter couple with repo and their dependencies
management, like Go
This means higher initial logistic effort to set those sub projects up, but it
can be done gradually.
> create NiFi sub projects to host NiFi REST client in different languages
> ------------------------------------------------------------------------
>
> Key: NIFI-7718
> URL: https://issues.apache.org/jira/browse/NIFI-7718
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Tools and Build
> Reporter: Simon Weng
> Priority: Minor
>
> We're seeing the need of NiFI REST clients in different languages, such as
> Python, Go, etc, so that software can be created to control and manage NiFi
> cluster and flows.
> Since the RESTful API is documented in OpenAPI spec v2, a client SDK can be
> generated via
> [openapi-generator|https://github.com/OpenAPITools/openapi-generator]
> Individual effort is seen from the community, such as:
> * [https://github.com/erdrix/nigoapi]
> * [https://github.com/simingweng/nifi-go-client]
> * [https://github.com/Chaffelson/nipyapi]
> It would be beneficial to the community to consolidate the effort and
> centrally maintain the Client SDK effort for everybody to use.
> Just like {{minifi}} being a sub project of NiFi, we can create sub project
> for different language bindings, such as:
> * apache/nifi-clients
> * apache/nifi-client-go
>
> A single repo like \{{nifi-clients}} can house all the languages that does
> not requires separate repo for publishing, \{{nifi-client-go}} is an
> exception because Go Module couples with its own repo.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
