You have learned that the Evidence API has four operations within the /Evidence/{id} path. Since each may have different requirements upon execution, it would be good to separate those in the assembly so that you can apply different policies to them. We’ll use operation-switch to set that demarcation.

Warning

Nesting an operation-switch component inside an if or switch construct, or another operation-switch component, is not supported.

To use the operation-switch, perform the following steps:

1. Make sure you are in the API Manager and have chosen the Develop APIs and products tile. Locate Evidence API and click on it:
2. Locate the Gateway tab and select it. Ensure you are in the Policies section. You will see an invoke policy, as shown in Figure 6.49:

Figure 6.49 – Evidence invoke policy

3. Drag and drop an Operation Switch component just before the invoke policy on the canvas.

From the Logic menu, drag and drop the Operation Switch component and release it before invoke, as shown in the following screenshot:

Figure 6.50 – Dragging the Operation Switch component to the canvas

The operation-switch component will then show before invoke, as shown in Figure 6.50. You will notice that there is an empty case displayed. You will start providing those cases:

Figure 6.51 – operation-switch

4. You already know that there are operations set for Evidence API. They were GET, PUT, DELETE, and PATCH.

5. On the operation-switch property panel and scroll down until you see case 0. Click on where it says search operations… and a list of operations will be displayed:

Figure 6.52 – Operations display for GET, PUT, DELETE, and so on

What you may have noticed is the operators you thought would show up (GET, PUT, DELETE, and so on) are not there. Instead, there are various values, such as readEvidence, updateEvidence, and so on. How did they get there? You’ll learn shortly, but you should finish this first.

6. Select readEvidence and click on Save.

7. Now, click on the Design tab. Then find the /Evidence/{id} path.

8. Scroll down to see Operations and expand it to choose GET, as shown in the following screenshot:

Figure 6.53 – Navigating to review operation details

Continue to scroll down the page until you see the Operation (optional) label:

Figure 6.54 – Adding an operation is good for readability and documentation

Notice how the Operation (optional) field is showing readEvidence. You saw this optional field when you added the PATCH method earlier, but you left it blank. Since you didn’t supply any Operation (optional) fields to PATCH, it will create a default name and list it on the case properties field on the invoke policy. Now you know how an Operation (optional) field works, you can continue.

9. Click on the Gateway tab so that we can finish our operation-switch cases.

10. Click on operation-switch to bring up the Properties pane. Your screen should show your Case 0 selection of readEvidence.

11. Finally, click on the Add case button, as follows:

Figure 6.55 – Adding more cases to operation-switch

When you click on Add case, it will add a new case field ready for your selection:

12. Then, click on search operations…. Notice the difference between an Operation (optional) field with data or left blank:

Figure 6.56 – The search operations… dropdown

You will choose updateEvidence to assign the PUT method to Case 1. Notice how readEvidence is not shown and the PATCH method you added is displayed in the dropdown. It shows your PATCH method and the path, instead of a readable operation (optional) name.

Tip

Having an Operation (optional) name makes your visual programming more readable.

13. Repeat step 11 to add the deleteEvidence case. Your updates should reflect on the canvas as three total cases, as follows:

Figure 6.57 – Three operations are set up