Just wanted to note a concern on the deprecation (and presumed removal) of the PostHTTP processor in the upcoming 2.0 release.
While yes, for traditional client interactions with an external HTTP service, utilizing InvokeHTTP for your POST operation is probably sensible. The concern is that there are a number of NiFi-to-NiFi transfers that leverage the "special sauce" that exists between PostHTTP and ListenHTTP. What special sauce? Namely, the extra negotiation that enables an automated serialization of NiFi flowfiles from one system to another. InvokeHTTP is just a "raw" HTTP client and doesn't share any special concern or support for NiFi-to-NiFi data transfer. Of course, if you remember the history, before there was any site-to-site functionality built into processor groups, the primary means of flowfile transport between NiFi systems was the PostHTTP / ListenHTTP combo. It was an easy way to facilitate transfer between two nifi systems. And from what I can tell, this "legacy" approach to NiFi data transfer is still being used heavily in certain operational contexts. Why? Because often it's the case that the _only_ traffic allowed between network boundaries is done via HTTPS. The site-to-site protocol provides its own ports and protocol operations that don't necessarily comply with such a network policy. And I believe there's still some lingering and/or demonstrated concern over the performance characteristics of the site-to-site protocol by dataflow managers. They have often reverted to using PostHTTP / ListenHTTP instead. While many of the other deprecated components seem logical, getting rid of this one just seems like change-for-the-sake-of-change. Is there any actual technical reason to deprecate and remove PostHTTP from the standard nar? Is it causing a burden to the product itself? Or was the decision just more like, "hey it's dumb not to use InvokeHTTP for all HTTP client operations" and maybe not realize the alternative use case that PostHTTP enables? Thanks for any feedback. /Adam
