[jira] [Commented] (NIFI-9015) Ability to derive custom Rest API processes from InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580896#comment-17580896 ] David Handermann commented on NIFI-9015: Thanks [~otto]! > 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 >Assignee: 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.20.10#820010)
[jira] [Commented] (NIFI-9015) Ability to derive custom Rest API processes from InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580890#comment-17580890 ] Otto Fowler commented on NIFI-9015: --- [~exceptionfactory]: I have been following the PR review and I think that great work. I'll close this ticket. > 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.20.10#820010)
[jira] [Commented] (NIFI-9015) Ability to derive custom Rest API processes from InvokeHTTP
[
https://issues.apache.org/jira/browse/NIFI-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580809#comment-17580809
]
David Handermann commented on NIFI-9015:
NIFI-10244 introduced a new {{WebClientServiceProvider}} Controller Service and
{{WebClientService}} interface for HTTP communication. It seems like building
on these components would provide a better fit for extensible components as
opposed to refactoring InvokeHTTP for extension. What do you think [~otto]?
> 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.20.10#820010)
