Step 4. Test the API

Test your API locally before deploying it to the cloud. You run the API in Anypoint Code Builder, send requests using Postman, and use the built-in debugger to inspect the Mule message at each step. You also add input validation and logging to make the API more robust.

Step 4.1: Run and Test Your API

Open the Run and Debug panel.
Show me how
- Click (Run and Debug) in the activity bar.
- Use the keyboard shortcuts:
  
  Mac: Cmd+Shift+d
  
  Windows: Ctrl+Shift+d
- In the desktop IDE, select View > Run.
Run the Mule app.

1	Click to open the Run and Debug panel.
2	Click the button to run the Mule app.

The Output panel shows startup progress. Wait for Application started successfully.

Open Postman and send a GET request:

http://localhost:8081/api/greeting?name=World

Verify you receive:
```
{
  "message": "Hello, World!"
}
```
Your API works! Now let’s add validation and debugging.
Click (Stop) in the debug toolbar.

Step 4.2: Add Validation

Now add validation to ensure your API handles requests without a name parameter.

In the canvas, navigate to your get:\greeting flow.

Your flow currently has a Logger component followed by a Transform component from the previous step.
Click (Add component) before the Logger component (at the start of the flow).
Search for Choice and select it from the results.

The Choice component adds a When branch and an Otherwise branch. Execution continues to Logger and Transform after the Choice unless the When branch stops it (with Raise Error).
Click (Add component) inside the When branch.
Search for Raise error and select it.

Add the Raise Error component to the When branch before setting the condition. The When branch must contain at least one component or the XML will be invalid.
Configure the Raise Error component:
- Type: APP:BAD_REQUEST
- Description: Name parameter is required
Click the Choice component’s When condition, and enter this expression:
```
#[attributes.queryParams.name == null or attributes.queryParams.name == ""]
```
This expression checks whether the name query parameter is missing from the request or sent as an empty string. The name parameter is the one you defined in your API spec at /greeting?name=.
Save your changes.

Your flow order is now: Choice → Logger → Transform. When the name query parameter is missing or empty, the When condition triggers the Raise Error component and the flow stops. When name has a value, execution continues to Logger and Transform.

Step 4.3: Test the Validation

Start your application by clicking (Run) in the debug toolbar.
In Postman, test with a valid name parameter:
```
http://localhost:8081/api/greeting?name=World
```
You should receive: {"message": "Hello, World!"}
Test without the name parameter:
```
http://localhost:8081/api/greeting
```
You should receive a validation error with status 400.
Click (Stop) in the debug toolbar.

Your API now validates input before processing.

Step 4.4: Add Logging

Logging helps you see what’s happening inside your flows.

Click the Logger component and configure it:
- Message: Click fx to switch to expression mode, then enter:
  #["Received greeting request for name: " ++ (attributes.queryParams.name default "not provided")]
  This message logs the name query parameter value or "not provided" if it’s missing.
- Level: INFO
Save your changes.

Step 4.5: Test with Logging

Start your application by clicking (Run) in the debug toolbar.
Open the Terminal panel to see your application logs:
- Mac: Cmd+\ or select View > Terminal
- Windows: Ctrl+\ or select View > Terminal
  
  Logger output appears in the Terminal panel, not the Output panel. The Terminal shows the live Mule runtime log as requests are processed.

Send a request with Postman:

http://localhost:8081/api/greeting?name=World

In the Terminal panel, you’ll see a log entry similar to:

INFO  [hello-world-impl].get:\greeting  Received greeting request for name: World

Send a few more requests and watch the logs update.
Click (Stop) when done.

Step 4.6: Use Breakpoints for Debugging

Breakpoints pause execution so you can inspect the Mule message at a specific point in your flow.

In the canvas, select the context menu for the Logger component, and then select Add Breakpoint.

A red dot appears, which represents a breakpoint.
Click (Run and Debug) in the activity bar to open the Run and Debug panel.
Select Debug Mule Application to start your application in debug mode.

Send a request from Postman:

http://localhost:8081/api/greeting?name=World

Return to Anypoint Code Builder.

Execution pauses at the breakpoint. The debug toolbar appears at the top of the editor, and the Variables panel appears in the Run and Debug panel.

The Variables panel is in the Run and Debug sidebar, not at the bottom of the IDE. If you don’t see it, make sure the Run and Debug panel is open ( icon in the activity bar).
In the Variables panel, expand Mule Message to inspect:
- payload: The current message content
- attributes: HTTP request details, including headers, query parameters, and URI
- vars: Any flow variables set during execution
Click Continue in the debug toolbar to resume execution and complete the request.
Click (Stop) when done.

What You Learned

You ran the API locally and tested it with Postman, then added input validation using a Choice router and Raise Error component to handle missing name parameters. You configured a Logger to record each request, then used Anypoint Code Builder’s debugger, including breakpoints and the Variables panel, to pause execution and inspect the Mule message at each step.

Developer Deep Dive

Explore advanced testing capabilities:

What’s Next

With your APIs fully tested locally, you’ll deploy them to CloudHub 2.0 to make them accessible to other applications and users.