Support for 'batch' mode, i.e. multiple lines of input data

[rstudio]

Support for 'batch' mode, i.e. multiple lines of input data

[trestletech]

Hi Frank,

How much control do you have over the client sending the data? It seems to me that alternative formats might be a better fit for this structure of data. I'm thinking for instance that you could pass in JSON a la endpoint?data="[{a:1, b:2}, {a:3, b:4}] and parse the data frame out in that way.

I'm pushing back just because any time I've had to work with repeated query string parameters in any programming language/framework, it's always felt cludgy. So that idea makes me a little reserved about diving in to support the feature (though of course you can do whatever you want in your fork!).

I don't see any obvious problems with the method you proposed, nor am I sure why you'd be getting those errors, but I'm not totally surprised that it didn't work. I can imagine that some list of arguments to pass in is being indexed by parameter name, so as it encounters multiple parameters with the same name some get dropped or something.

[FrankPortman]

Hi,

Thanks for the quick reply.

Actually I ended up being able to fix it. The issue was curl being unhappy with newline characters in the data argument. If you do the curl command with a file input instead:

curl --data "`cat test_file`"

or

curl --data-binary @test_file 

then it seems to work as expected. A side benefit is that passing in just one row still works!

I've considered doing it the way you are suggesting as well and then unwrapping it within the function itself and I may end up going that route in the future. Is there anywhere you can point me to to learn more about the JSON input format you're suggesting? I'm only used to interfacing with plumber using --data "a=1&b=2...".

[trestletech]

I don't have a formal reference on the topic, but you could look at serializing with jsonlite::toJSON() and within your plumber function deserializing using jsonlite::fromJSON(). In that case, the variable you're trying to parse is just a string.

That format seems a little more typical, at least from what I've seen, but I don't know that there are any compelling reasons to prefer it over your approach.