That’s correct - if you wanted to run a plan that had never been run before, you would need to go down the SA REST API route (as opposed to the alternative platform REST API route I describe).
And I fully get that you might not want to provide a full blown web front end for using the REST API - totally understandable - we really just put that demo application in there so folks could see how it could be used (and even use something like firebug to see the HTTP traffic back and forth between the application and the REST API for reference).
But I don’t think you’ll be able to get away from the necessity to provide parameter and target values, and that would go not just for SA plan actions, but for any action you’re trying to create. Every action can potentially be different, and for an SA plan, that is just taken a step further due to the fact that every step in the plan can be targeted at different machines potentially.
The easiest scenario to programmatically support is the execution of a plan that was run before, exactly like it was run before (by that I mean it targets the same computers and uses the same parameter values). In this case, you should just be able to create a “copy” of the existing plan action using the platform REST API’s functions I linked to above. This would be useful let’s say for repetitive tasks that are done on the same machine(s).
But in pretty much any other case where you’re deviating from that, you’ll need to provide the action (and again, this goes for any action, not just an SA plan action) with the variables it needs to know what it’s doing (parameters, if it takes any) and where it’s doing it (one or more targets). By going the REST route the client needs to perform the job of the UI in terms of soliciting that input.