HTTP Connector: Building Your First REST API in Mule

You've already used the HTTP Connector once — the Listener component in the "Hello World" flow back in Phase 2. This post goes deeper: building a proper REST API with multiple endpoints, path variables, query parameters, and the difference between the HTTP Listener (receiving requests) and HTTP Requester (making requests to other APIs). This is the foundation every System and Process API in your future projects will be built on.

Two Sides of the Same Connector

The HTTP Connector has two distinct roles, and beginners sometimes conflate them:

• HTTP Listener — a source that receives incoming requests (your Mule app acts as a server)
• HTTP Request — a processor that sends outgoing requests to another API (your Mule app acts as a client)

A single flow can use both: receive a request via Listener, call another system via Request, then respond. This is extremely common — it's essentially what a Process API does.

Building a Small REST API: Product Lookup

Let's build something more realistic than "Hello World" — a simple product lookup API with two endpoints:

• GET /products — list all products
• GET /products/{id} — get one product by ID

Step 1: Configure the HTTP Listener

Same as before: drag an HTTP Listener onto the canvas, configure host/port (e.g. localhost:8081). This time, instead of a single fixed path, set the path to:

/products/*

The * wildcard lets this single listener catch requests to both /products and /products/{anything}, which we'll route based on the exact path inside the flow.

Step 2: Route with a Choice Router

Add a Choice component (introduced back in the Flows/Sub-Flows post) right after the Listener, to branch based on whether an ID was provided:

%dw 2.0
---
attributes.uriParams.id

• When branch: if attributes.uriParams.id exists → handle single-product lookup
• Otherwise branch: → handle listing all products

Step 3: Reading Path Variables

To capture {id} from a URL like /products/42, set your listener path to:

/products/{id}

Then anywhere downstream, access it via:

%dw 2.0
output application/json
---
{
  requestedId: attributes.uriParams.id
}

Step 4: Reading Query Parameters

For a request like /products?category=electronics, query parameters are available the same way, under queryParams instead of uriParams:

%dw 2.0
output application/json
---
{
  category: attributes.queryParams.category
}

Step 5: Return the Right HTTP Status

By default, successful responses return 200 OK. To return something else — like 404 Not Found when a product ID doesn't exist — you set it on the HTTP Listener's response, typically via a variable:

%dw 2.0
output application/json
---
{
  httpStatus: 404,
  body: { error: "Product not found" }
}

Getting status codes right matters more than beginners initially expect — API consumers (and automated tests) rely on them to understand what happened, not just the response body.

Calling Another API: HTTP Request

Now the other direction. Say your product data actually lives behind another API, and your flow needs to call out to fetch it. Add an HTTP Request component:

1. Search the Mule Palette for "HTTP" and drag Request onto the canvas
2. Configure a connection to the target API's base URL
3. Set the Method (GET, POST, PUT, DELETE) and Path

%dw 2.0
output application/json
---
{
  productId: attributes.uriParams.id
}

This might be the request body if calling a POST endpoint, or you'd set query parameters/path directly in the Request component's configuration if calling a GET endpoint.

Realistic pattern: HTTP Listener receives a request → HTTP Request calls an internal System API → Transform Message reshapes the response → the reshaped data goes back out through the original Listener. This three-step shape — receive, call out, respond — is the backbone of an enormous share of real Mule flows.

A Note on Building Real APIs: Design First

In the Anypoint Platform walkthrough earlier in this series, we mentioned Design Center — where APIs get designed (usually in RAML or OAS/OpenAPI) before implementation. In a real team environment, you'd typically define your /products and /products/{id} contract in Design Center first, then import that specification into Studio to scaffold your flow automatically. For learning purposes, building it directly in Studio first (as we just did) is the faster path to understanding the mechanics — but know that design-first is the production-grade habit to build toward.

What's Next

APIs frequently need to read and write real data, not just return hardcoded values. Next, we connect to an actual database.

Next up in this series: Database Connector: Connecting Mule to MySQL/PostgreSQL

visit ebook site - https://techebooks.myinstamojo.com/