need for pseudo code as a step in the workflow

[swaldron58]

Using our sig-travel experiences to explain a need for pseudo code as a step in the workflow, or other means to achieve the same goal.
I see the spec to have two main uses, mostly complementary, to support automation and to communicate to the API consumer how to use my APIs. The goal of both is to reduce the labor needed to get my APIs implemented and quickly producing value to both parties. I want to avoid my API consumer needing to go through extensive testing against my “copy” test system to fully understand some of the complexities and edge cases. I need the flexibility in the same workflow description to present as a step the analysis of the previous step results to outline to potential options of which following step to use. Pseudo code is a reasonable term for this need as many statements would be of the if-then-else nature. As an API provider it is in my best interest to in effect do some of the work for my API consumer because as I said, I want them up and running faster to create revenue for me. It may also help to understand that most APIs in travel (and elsewhere) are layered on an array of legacy systems that are still stubbornly stateful. I can not make my APIs as clean and REST compliant as I would like to. It’s gets weird and complicated. As an example for most airline systems one has a very tight window to pay after booking a seat or that seat goes back to inventory. If I am a travel consolidator (switch) many of the app level error conditions I just pass on from the source supplier. That means I have to warn that a result of “incomplete” means something different pending if we are talking Marriott or Hilton. The weirdness of the backend system(s) manifests itself through the APIs which heavily affects the workflow of the APIs. I need a means to explain and add context as part of the workflow description. Otherwise I am still dependent on other forms of documentation which never stay in sync and are not testable. Comments could certainly be used to explain some of this weirdness but would prefer to still have a means to express logic that is testable. This may be too aggressive for tooling in the near term but should be a goal. I need a means to verify my workflow description is not itself broken.
I would agree with anyone this will get complicated. In effect a close association between workflows descriptions and test use cases. But what a wonderful thing that would be.