Github user ijokarumawak commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2723#discussion_r189754939
--- Diff:
nifi-nar-bundles/nifi-standard-services/nifi-lookup-services-bundle/nifi-lookup-services/src/test/groovy/org/apache/nifi/lookup/RestLookupServiceIT.groovy
---
@@ -106,6 +106,37 @@ class RestLookupServiceIT {
}
}
+ @Test
+ void testHeaders() {
+ runner.disableControllerService(lookupService)
+ runner.setProperty(lookupService, "header.X-USER", "jane.doe")
+ runner.setProperty(lookupService, "header.X-PASS", "testing7890")
+ runner.enableControllerService(lookupService)
+
+ TestServer server = new TestServer()
+ ServletHandler handler = new ServletHandler()
+ handler.addServletWithMapping(SimpleJson.class, "/simple")
+ server.addHandler(handler)
+ try {
+ server.startServer()
+
+ def coordinates = [
+ "schema.name": "simple",
+ "endpoint": server.url + "/simple",
--- End diff --
In real use-cases, do we expect user to set 'server.url' at a LookupRecord
processor's user defined property?
As an alternative approach, I'd add `endpoint url` at RestLookupService to
define a template string to resolve target endpoint, and let callers such as
LookupRecord to pass required variables to complete the target endpoint.
For example:
- At RestLookupService
- Endpoint URL:
`https://some-api.example.com/buckets/${bucketId}/items/${itemId}`
- At LookupRecord processor
- bucketId as user-defined-property: ./bucketId (a record path to get a
value)
- itemId as user-defined-property: ./itemId (a record path to get a value)
By doing so, it also supports passing the entire endpoint URL:
- At RestLookupService
- Endpoint URL: `${endpoint}`
- At LookupRecord processor
- endpoint as user-defined-property: a record path to construct an URL
I'd expect RestLookupService to have more control on REST related
configurations, and callers just pass variables to make actual requests. How do
you think?
---