An application programming interface (API) is a way to interact with a software component. APIs provide the piping between a dashboard, backend processing, databases, packages, microservices, and distributed systems. In a payment-processing application, they let the UI request health status, file details, ACH batches, audit records, and other results without directly performing backend work. section 4.0 section 1.1 section 7.4
A REST API can be tested in a browser when it uses GET, but POST, PUT, and DELETE need other testing approaches. A web page outside Docker reaches an exposed API through localhost and its mapped port, whereas containers can use internal container addressing. Once a browser-based UI calls the API from a different origin, CORS must explicitly allow that origin and the required methods. section 3.4 section 7.5.2
Build an API incrementally around a useful application need:
- Start with a small GET endpoint returning hardcoded data to confirm routing and request handling before a database is required. section 4.3
- Separate related endpoints into routers, then register each router with the FastAPI application so its routes become reachable. section 4.3 section 9.5.3
- Shape returned data for the consuming UI. A simpler API response can be transformed into UI-specific interfaces and grouped records when that keeps an MVP easier to evolve. section 7.4.2
- Account for production-scale behavior: paginate large record sets and use asynchronous processing for long-running file uploads to avoid slow interfaces and request timeouts. section 4.3
- Begin a new API with a unit test, then implement the pieces needed to make it pass. section 11.8
Calling a health-status API from a web page
A D3.js page requests http://localhost:8000/health/status, receives health data, and renders each result as a list item. If the page runs at localhost:3000, the FastAPI service needs CORS middleware configured to allow that origin and GET requests. Generated starter code can accelerate the first version, but dependency versions and the endpoint URL still need review and adjustment. section 3.4
Listing 3.7 Updated sample page
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Health Check</title> #1
<script src="https://d3js.org/d3.v7.min.js"></script> #2
</head>
<body>
<h2>Health Check</h2> #2
<ul id="healthStatus"></ul> #2
<script>
// The URL for the API endpoint
const apiUrl = 'http://localhost:8000/health/status'; #3
// Use D3 to fetch the data from the API
d3.json(apiUrl).then(data => {
// Once data is fetched, populate the list
d3.select("#healthStatus") #4
.selectAll("li") #4
.data(data) #4
.enter() #4
.append("li") #4
.text(d => `${d.id} (${d.status})`); #4
}); #4
</script>
</body>
</html>
This page shows the concrete client-side API URL, D3 JSON request, and rendering flow for a health-status response. section 3.4
API documentation and management make an interface easier to discover and govern. FastAPI can generate OpenAPI documentation; an API manager can import that definition, assign a context and version, deploy a managed endpoint, generate keys, and route consumers through one entry point rather than directly exposing the backend port. section 12.1.3 section 4.6.4
An API is not fixed once its first endpoint works. Dashboard needs can reveal missing endpoints, response formats can change as real data replaces mocks, and a fuller payment dashboard would need additional create, update, delete, and undo operations. REST remains a practical baseline, while GraphQL can be explored alongside or instead of REST where appropriate. section 7.4 section 7.4.2 section 12.1.3
