make operation a route parameter

[hyperledger]

make operation a route parameter

[swcurran]

@TimoGlastra - @ianco is going to make this change tomorrow in the Test Harness (calling the API) and in the python backchannel used by ACA-Py and VCX. Once that is done, we're assuming you can make a comparable update in your work, and ideally produce a Swagger file that defines the interface. The expectation is that it is just a half day effort for what Ian is going to do - not a big deal.

It's a little weird since each backchannel will be defining the same API and will be able to generate the Swagger definition. The single Test Harness will be calling the interface. So basically, we need a "API-first" development mode where we update a common swagger definition, and then use that to define the routes for each backchannel. We'll think about that as we move forward.

[swcurran]

Thanks @TimoGlastra . Over to @ianco and @nodlesh for their thoughts.

My leaning is that this is the right way to go. It makes the API much more transparent, easier on devs and we can version the API as another mechanism to control what tests can be executed when using different TAs (Test Agents).

A question is the effort to switch. Ian, this seems like something you could knock off fairly easily for the Test Harness and at least in ACA-Py. Not so sure about VCX and Pico.

[ianco]

I agree this is a good suggestion. It would not be a huge effort to convert the aca-py or vcx backchannels.

(A bigger task is that the vcx backchannel needs to be brought up to the latest codebase, it is based on a 6-month-old version of vcx. The Pico backchannel was never fully built out (more of a POC) and Pico has also been rewritten over the past 6 months.)

[swcurran]

Sounds good. @nodlesh and @ianco -- let's discuss at the standup (or after) tomorrow about how to get there.

[nodlesh]

I agree as well; This would be a better cleaner approach. Though I would suggest we leave the old way in as well, temporarily, to support what is already there. We can migrate older backchannels to the new way as it becomes priority. We could also leave the old way there permanently was a way to allow calling into a specific backchannel to do operations not necessarily supported by other backchannels.

[swcurran]

Let's figure out a migration plan.

@TimoGlastra -- assuming we do the change to the Harness, what is the impact on what you have already done? I'm guessing it will be minor?

[TimoGlastra]

Awesome. This will indeed be a minor change for the .NET backchannel (think minutes). Once @ianco has made the necessary changes i'll update the endpoints. I'll also create the swagger definition while implementing the different operations.

How are topics without named operations going to be handled (e.g. the schema topic only has one operation)? My preference would be to give every action an operation - even if the topic only has one operation. For consistency and future proofing.

@swcurran It's indeed a bit weird and different than most APIs - which have multiple clients and a single server.

[swcurran]

@TimoGlastra -- this is done now -- #69 and merged. This will break your stuff, but easily fixed, right?

Onward!

[TimoGlastra]

Great! Easily fixed indeed