[
https://issues.apache.org/jira/browse/NIFI-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otto Fowler updated NIFI-9015:
------------------------------
Description:
In setups with custom development, there is a lot of boilerplate customization
to InvokeHTTP around some known set of rest apis. As such flow developers /
users have to 'know' and understand these things in order to setup possibly
multiple InvokeHTTP instances with these details.
Some users may instead want to create a top level derived processor with custom
setup and parameters for a specific rest api for easy configuration and
deployment.
The
[InvokeAWSGatewayApi|https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-aws-nar/1.14.0/org.apache.nifi.processors.aws.wag.InvokeAWSGatewayApi/index.html]
processor ( which itself had to be copied from InvokeHTTP because of this
limitation ) offers this, such that you can create a derived processor for a
custom AWS Web Gateway service.
With a coming processor registry, the ability for people to contribute
specialized processors for certain APIs would be great. These may be a subset
or a super set of the existing properties. We may also move the 'base'
properties to a new UI tab in the configuration, such that you can add custom
extra configuration in the first focus tab. We could also allow for removing
properties as well from the base tab, etc etc
This task would involve refactoring the invokeHTTP processor such that there is
a reusable base, with the InvokeHTTP processor being a pass-through default
implementation ( IE> a new derived from base would have all the same features
as InvokeHTTP ).
was:
In setups with custom development, there is a lot of boilerplate customization
to InvokeHTTP around some known set of rest apis. As such flow developers /
users have to 'know' and understand these things in order to setup possibly
multiple InvokeHTTP instances with these details.
Some users may instead want to create a top level derived processor with custom
setup and parameters for a specific rest api for easy configuration and
deployment.
The
[InvokeAWSGatewayApi|https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-aws-nar/1.14.0/org.apache.nifi.processors.aws.wag.InvokeAWSGatewayApi/index.html]
processor ( which itself had to be copied from InvokeHTTP because of this
limitation ) offers this, such that you can create a derived processor for a
custom AWS Web Gateway service.
With a coming processor registry, the ability for people to contribute
specialized processors for certain APIs would be great.
This task would involve refactoring the invokeHTTP processor such that there is
a reusable base, with the InvokeHTTP processor being a pass-through default
implementation ( IE> a new derived from base would have all the same features
as InvokeHTTP ).
> Ability to derive custom Rest API processes from InvokeHTTP
> -----------------------------------------------------------
>
> Key: NIFI-9015
> URL: https://issues.apache.org/jira/browse/NIFI-9015
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Otto Fowler
> Priority: Major
>
> In setups with custom development, there is a lot of boilerplate
> customization to InvokeHTTP around some known set of rest apis. As such flow
> developers / users have to 'know' and understand these things in order to
> setup possibly multiple InvokeHTTP instances with these details.
> Some users may instead want to create a top level derived processor with
> custom setup and parameters for a specific rest api for easy configuration
> and deployment.
> The
> [InvokeAWSGatewayApi|https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-aws-nar/1.14.0/org.apache.nifi.processors.aws.wag.InvokeAWSGatewayApi/index.html]
> processor ( which itself had to be copied from InvokeHTTP because of this
> limitation ) offers this, such that you can create a derived processor for a
> custom AWS Web Gateway service.
> With a coming processor registry, the ability for people to contribute
> specialized processors for certain APIs would be great. These may be a
> subset or a super set of the existing properties. We may also move the
> 'base' properties to a new UI tab in the configuration, such that you can add
> custom extra configuration in the first focus tab. We could also allow for
> removing properties as well from the base tab, etc etc
> This task would involve refactoring the invokeHTTP processor such that there
> is a reusable base, with the InvokeHTTP processor being a pass-through
> default implementation ( IE> a new derived from base would have all the same
> features as InvokeHTTP ).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
