Testing Mock Banking API Account and Transfer Endpoints

Good to see you again. You have now oriented yourself in an Angular workspace and mapped familiar React concepts to Angular components, templates, signals, lifecycle hooks, and dependency injection. Before an Angular service consumes banking data, establish that the API contract itself is reachable and behaves as expected.

In this lesson, you will run a self-contained mock banking API, verify account retrieval and transfer submission with curl, and inspect the same requests in Chrome DevTools. This mirrors a useful enterprise debugging habit: first isolate the transport and contract from the UI, then investigate Angular code only if the endpoint works independently.

---

What “verify an endpoint” actually means

A successful-looking screen is not proof that an API integration is correct. Independently verifying an endpoint means checking these facts:

1. The server is running at the expected host and port.
2. The route and HTTP method are correct, such as GET /accounts or POST /transfers.
3. The request contract is correct: JSON body, headers, and expected field names.
4. The response status communicates the result, such as 200 OK or 201 Created.
5. The response body shape is suitable for the DTO Angular will eventually model.

For this course, the mock API is intentionally simple. It supports HTTP interaction and realistic-ish data, but it does not model banking behavior: it will not authenticate a customer, check a balance, deduct funds, validate an IBAN, or generate a real payment reference. A successful mock transfer means only that a JSON record was accepted and stored locally.

That separation is valuable. It lets you learn Angular HTTP, RxJS, forms, and error handling without needing access to the company gateway, backend services, or Keycloak.

---

Create a local banking mock

Use a small Node project separate from your Angular application. This keeps mock data and mock-server dependencies out of the SPA source tree.

From a workspace folder of your choice:

mkdir gcb-wmp-practice
cd gcb-wmp-practice
mkdir mock-api
cd mock-api
npm init -y
npm install --save-dev json-server

The current json-server documentation describes a beta v1 release. Use the command and query syntax from its current documentation rather than assuming that an older tutorial’s --watch command or query parameters still apply.

Create a file named db.json inside mock-api:

{
  "accounts": [
    {
      "id": "ACC-1042",
      "nickname": "Primary Current Account",
      "iban": "GB29NWBK60161331926819",
      "availableBalance": 12500.75,
      "currency": "GBP"
    },
    {
      "id": "ACC-2098",
      "nickname": "Investment Reserve",
      "iban": "GB82WEST12345698765432",
      "availableBalance": 48200,
      "currency": "GBP"
    }
  ],
  "transfers": []
}

Start the API while still in the mock-api directory:

npx json-server db.json

Leave that terminal running. JSON Server should report that it is serving on:

http://localhost:3000

Open the following URL in a browser:

http://localhost:3000/accounts

You should receive the accounts array from db.json. A direct browser visit is useful for a quick check, but it can make only a GET request. Use curl or a browser fetch call when you need to inspect a POST request.

Your local mock contract

For the remainder of this lesson, treat these as the API endpoints:

Intent	Method	Endpoint	Expected result
List accounts	GET	http://localhost:3000/accounts	Array of account objects
Get one account	GET	http://localhost:3000/accounts/ACC-1042	One account object
Submit a mock transfer	POST	http://localhost:3000/transfers	Created transfer record

A production gateway may eventually expose a versioned path such as /api/accounts, and its transfer endpoint may return a purpose-built response DTO. Do not infer a production URL design from this local mock. Its job is to provide a stable contract for practice.

---

Verify account endpoints with curl

curl is a command-line HTTP client. It gives you a fast way to isolate API behavior from routing, Angular change detection, template errors, and browser state.

First, confirm it is installed:

curl --version

Now request the account collection:

curl -sS -i http://localhost:3000/accounts

The flags have distinct purposes:

• -sS hides the progress meter but still reports errors.
• -i includes the response headers before the response body.

Look for a successful HTTP status such as:

HTTP/1.1 200 OK

Then confirm that the response body is a JSON array with the expected properties: id, nickname, iban, availableBalance, and currency.

Request one known account by ID:

curl -sS -i http://localhost:3000/accounts/ACC-1042

This time, the body should be one object rather than an array. Test a deliberately missing ID too:

curl -sS -i http://localhost:3000/accounts/ACC-NOT-FOUND

A 404 Not Found is a useful result here. It confirms that you can distinguish a valid route with a missing resource from a server that is unreachable.

For a deeper view of the request and response headers, use verbose mode:

curl -sS -v http://localhost:3000/accounts/ACC-1042

With -v, request information is printed with a > marker and response headers with a < marker. This is particularly useful later when you need to confirm an Authorization header, a request URL, or a server error response.

If you have jq installed, it can make compact JSON much easier to inspect:

curl -sS http://localhost:3000/accounts | jq

curl transports text; it does not validate or format JSON by itself.

---

Submit and verify a mock transfer

Create a second file beside db.json, named transfer-request.json:

{
  "sourceAccountId": "ACC-1042",
  "targetIban": "GB82WEST12345698765432",
  "amount": 125.5,
  "currency": "GBP"
}

This is a deliberately small transfer request contract. The field names are chosen to resemble the eventual Angular form and DTO work:

• sourceAccountId identifies the debited account.
• targetIban identifies the recipient account.
• amount is a JSON number, not a quoted string.
• currency is explicit rather than implied.

Send it:

curl -sS -i --json @transfer-request.json http://localhost:3000/transfers

The --json option:

• sends the contents of the file as the request body,
• sets Content-Type: application/json,
• sets Accept: application/json,
• uses POST when sending data unless you explicitly choose another method.

Inspect the response. JSON Server should return a success status, normally 201 Created, and the newly created transfer object. The server may add an id; do not assume a particular generated ID value.

Now make a follow-up request:

curl -sS -i http://localhost:3000/transfers

The transfer collection should contain your submitted record. This final read is important: it verifies that the server accepted the request at the expected path and persisted it in the mock dataset.

Because this mock writes to db.json, each successful POST changes your local fixture data. When you want a clean lab state, reset the transfers value manually:

"transfers": []

Then restart JSON Server if necessary. In a team repository, fixture changes should be intentional and reviewed; avoid committing accidental data produced during manual API checks.

A concise curl debugging guide

Symptom	Likely cause	First check
curl: (7) Failed to connect	Server is not running or port is wrong	Terminal running JSON Server; port 3000
404 Not Found for /accounts	Resource name differs from the db.json key	Exact spelling of accounts and URL
Server fails to start	Invalid JSON in db.json	Missing commas, quotes, braces, or brackets
201 Created, but no balance changes	Expected limitation of this mock	JSON Server stores data; it has no transfer business logic
Angular later fails but curl succeeds	Browser-specific issue	Network panel, CORS, interceptor, route, or UI code

---

Inspect the same traffic in Chrome DevTools

curl proves the API works independently. Chrome DevTools proves what the browser actually attempted. This distinction becomes essential once requests originate from an Angular app and pass through interceptors.

Start your Angular application in a separate terminal if it is not already running:

ng serve

Open the Angular app at its local development URL, typically http://localhost:4200. Then:

1. Open Chrome DevTools with F12 or Ctrl+Shift+I on Windows/Linux, or Cmd+Option+I on macOS.
2. Open the Network tab.
3. Click the clear button to remove earlier requests.
4. Select the Fetch/XHR filter.
5. Open the Console tab and run the account request below.
6. Return to Network and select the accounts request.

fetch('http://localhost:3000/accounts')
  .then((response) => response.json())
  .then(console.log)
  .catch(console.error);

For the transfer request, run this once. It creates another local mock record:

fetch('http://localhost:3000/transfers', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    sourceAccountId: 'ACC-1042',
    targetIban: 'GB82WEST12345698765432',
    amount: 125.5,
    currency: 'GBP'
  })
})
  .then(async (response) => ({
    status: response.status,
    body: await response.json()
  }))
  .then(console.log)
  .catch(console.error);

For each request, inspect these DevTools areas:

DevTools area	What to verify
Headers, General	Request URL, request method, and status code
Headers, Request Headers	Content-Type on the transfer request; later, a bearer token added by an interceptor
Payload	The JSON body sent for the POST /transfers request
Response or Preview	The returned account data or created transfer object
Timing	Whether the delay is network wait, server work, or download time

Because the Angular app normally runs on port 4200 and JSON Server on 3000, this is a cross-origin browser request. A JSON POST can cause the browser to send an OPTIONS preflight request before the actual POST. If that happens, you may see both entries in Network. JSON Server is generally convenient for this practice because it supports browser access, but the key lesson is broader:

A successful curl request does not prove a browser request will succeed, because curl does not enforce browser CORS rules.

You will diagnose CORS preflights systematically in the authentication and browser-security module. For now, recognize that the Network panel is where you confirm what the browser sent and what the server permitted.

---

Lab completion checklist

Before moving on, make sure you can do all of the following without Angular HTTP code:

• Run JSON Server locally from a db.json banking fixture.
• Retrieve the account list and one individual account with curl.
• Identify 200, 201, and 404 responses.
• Submit a JSON transfer payload using curl --json.
• Confirm the posted transfer by retrieving /transfers.
• Use Chrome DevTools Network to inspect a browser GET and POST.
• State the difference between “the API works with curl” and “the API works from the Angular application.”

---

Key takeaways

A mock API gives you a reliable local stand-in while the real GCB-WMP gateway and services are unavailable. JSON Server exposes collection keys in db.json as REST resources, allowing you to practice GET and POST workflows with account and transfer data.

Use curl to verify method, URL, request body, status, headers, and response shape independently of Angular. Use Chrome DevTools Network to see the browser’s actual request, including headers, payload, response, and any cross-origin behavior. These are complementary tools, not substitutes.

Next, you will configure an environment-specific API gateway URL so Angular can target the local mock in development without hard-coding URLs in services or placing secrets in frontend configuration.