[
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 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.
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]|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 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
