The problem you are addressing is in spirit very, very similar to what Expect.pm addresses. The only difference is that you are communicating over an HTTP connection, whereas Expect communicates over a pseudoterminal. But both are based on a request/reply model.
You describe this as "recursion", but to me it seems like that's an artifact of your implementation. You could just as well change either the description or implementation to a series of dependent request/reply transactions. (In general, it seems like the pattern is more of a graph than a tree. Any request could result in a "login timed out" reply, and the subsequent login request would be the same for a whole bunch of different original requests.) You could model it as a state machine, but I think a push-down automaton might be a better fit. Which itself makes me think of YACC -- perhaps its grammar input is a good model for a descriptive format?
This also reminds me of Prolog. "My whole task is complete if I add a record for X, make sure the user permissions for Y are set up correctly, and I post an update to the news feed. Adding a record for X is complete if I look up "smurf livers" as a category, and I use that category to define..." etc. Using a similar reduction model, you might be able to figure out what things can be performed in parallel, or at least give nice error output: "Task A failed because subtask c2 failed."
Re: Data driven HTTP interaction
Replies are listed 'Best First'.
Many thanks for the reply. I'm glad to see you've looked beyond the specific implementation. Your ideas are certainly worth thought.
I will almost certainly play with the idea in your 2nd point. I may be painting myself into a corner with my current recursive implementation. Your idea seems a lot more flexible, and will probably lead to definitions that are simpler to understand (at least for some definition of "understand").
I must admit the Prolog-esque solution sounds like a lot of fun. I'm not sure it would be worth the conceptual hurdle, but then again, maybe it would! Hmm.