Getting Started with FastAPI: Understanding Frontend-Backend Separation and RESTful API Design

Why You Should Understand Web Development Patterns First

FastAPI is currently the highest-performing Python web framework and is increasingly regarded as the go-to choice for backend development. But before diving into FastAPI syntax, a few key concepts are worth clarifying — especially web development patterns. Understanding who FastAPI was built for is what makes its design philosophy truly click.

This article is based on the FastAPI: From Beginner to Pro tutorial series by Bilibili creator 老肖. It focuses on FastAPI's foundational positioning, the concept of frontend-backend separation, and RESTful API conventions — the foundational content that beginners most often skip, yet matters the most.

Two Web Development Patterns: Coupled vs. Separated

Frontend-Backend Coupled (Not Separated)

In a "coupled" architecture, everything the browser sees — the UI, interactive effects, and data — is served by a single server.

In this model, when the browser makes a request, the application server queries the database, handles business logic, and renders a complete HTML page before sending it back. In other words, developers write business logic, data processing, and page rendering all within the same server.

This approach is also known as Server-Side Rendering (SSR) and was virtually the only option in the early days of the web. PHP, JSP, and ASP.NET are classic examples — the server merges data with HTML templates in memory and transmits the complete HTML string to the browser. This approach is SEO-friendly and offers fast initial page loads, but as business complexity grows, the tight coupling between frontend and backend becomes a serious problem: UI design must be finalized before backend development can proceed, parallel development is impossible, and splitting the tech stack becomes difficult. Today, this pattern is mostly background knowledge worth being aware of.

Frontend-Backend Separated

Frontend-backend separation is the dominant choice for enterprise-level web projects today — according to the tutorial, over 90% of enterprise applications use this pattern.

The rise of frontend-backend separation is closely tied to the widespread adoption of Ajax. In 2005, Google Maps made heavy use of Ajax for seamless data loading, sparking an industry-wide rethink of "dynamic web" experiences. Frontend frameworks like AngularJS (2010), React (2013), and Vue (2014) followed, giving the frontend the ability to independently handle complex interaction logic — and that's when separation truly became mainstream engineering practice.

The core idea is splitting responsibilities by technology:

• Frontend server (static file server): Hosts HTML, CSS, JavaScript, images, and other static assets. Responsible for UI rendering and interactive effects.
• Python application server (backend server): Handles business logic and exposes a unified API that returns data.

The most defining characteristic of this architecture is at least two servers: one dedicated to the frontend, one to the backend. This means that once requirements are confirmed, frontend and backend teams can develop in parallel without waiting on each other — dramatically improving overall efficiency.

In this architecture, the browser requests the frontend server for UI and the backend server for data. The backend only handles logic and data — it doesn't care whether the client is a browser, a mobile app, or a WeChat Mini Program.

It's worth noting that while XML was once a common data format for backend responses, today over 95% of web, desktop, and mobile applications use JSON. JSON (JavaScript Object Notation) was popularized by Douglas Crockford around 2001, with syntax derived directly from JavaScript object literals. Compared to XML, JSON payloads are typically 30–40% smaller, parse faster, and are supported natively by virtually every major programming language — Python's json module and JavaScript's JSON.parse() both handle JSON with zero dependencies. This engineering convenience is something XML simply can't match.

FastAPI's Role: Built for Frontend-Backend Separation

With both patterns in mind, FastAPI's core positioning becomes clear — it was designed from the ground up to serve frontend-backend separated architectures.

Built on Starlette Under the Hood

FastAPI is built on top of Starlette. Starlette is a lightweight ASGI framework developed by Tom Christie (also the author of Django REST Framework), released in 2018. ASGI (Asynchronous Server Gateway Interface) is the async successor to the traditional WSGI, designed specifically for long-lived connections like WebSockets and HTTP/2 — it's an async framework built natively for API development and backend services.

FastAPI's creator, Sebastián Ramírez, chose Starlette as the foundation precisely for its native async support and minimal performance overhead. In TechEmpower benchmarks, Starlette-based frameworks perform close to Node.js and Go — far ahead of traditional synchronous Python frameworks like Django and Flask.

Can FastAPI be used for coupled (non-separated) projects? Yes. Because it's built on Starlette, FastAPI also supports integrating the Jinja2 template engine for server-side HTML rendering. But according to the official documentation, FastAPI's primary focus remains backend development in a frontend-backend separated architecture.

In short: FastAPI is primarily a backend API framework, with some template rendering capability — but at its core, it's a high-performance Python web backend framework built for modern architectures.

API Interfaces and RESTful Design Explained

What Is an API Interface?

API stands for Application Programming Interface — it's the data access entry point that an application exposes to the outside world. This entry point can be a function, a class, or a URL. Clients send requests to call that entry point and exchange data.

The two dominant API interface conventions today are REST and RPC. RPC has a relatively small market share, and while Python can implement RPC, REST remains the mainstream — it's both convenient and relatively secure.

The Core Idea Behind RESTful APIs

REST stands for Representational State Transfer. It was formally introduced by Roy Fielding in his 2000 doctoral dissertation, Architectural Styles and the Design of Network-based Software Architectures. Fielding was one of the principal designers of the HTTP/1.1 protocol, and REST is essentially a systematic articulation of HTTP's design philosophy. REST is not a technical standard but an architectural style with six constraints, including statelessness, a uniform interface, and resource identification. Strictly speaking, only APIs that satisfy all these constraints are truly "RESTful" — most real-world APIs only implement a subset. Don't get too hung up on the name; at its core, it's a resource-oriented API design convention.

The central idea of REST is: treat every API interface as an operation on a resource (i.e., data). The backend's job is to expose access interfaces for data resources, and the URL path a client accesses represents the resource being operated on.

For the same resource, different HTTP methods distinguish the type of operation. The HTTP protocol assigns clear semantic conventions to each method: GET retrieves a resource and must be idempotent with no side effects; POST creates a new resource; PUT fully replaces a specified resource and must be idempotent; PATCH partially updates a resource; DELETE removes a resource. The elegance of this design is that the URL only needs to describe what is being operated on, while the method describes how — a clean separation of concerns:

Operation	HTTP Method	Example Path
Add a student	POST	/student
Get all students	GET	/student
Get a specific student	GET	/student/1
Update a specific student	PUT	/student/1
Delete a specific student	DELETE	/student/1

The combination of "a unified resource path + different HTTP methods" cleanly expresses create, read, update, and delete operations on data. This is the essence of RESTful design.

Summary

As the first step in learning FastAPI, this article skipped the rush to write code and instead laid three foundational pieces:

1. Understanding the essential difference between frontend-backend separation and coupling;
2. Clarifying FastAPI's positioning — built on Starlette, focused on backend APIs;
3. Grasping the basic design philosophy behind API interfaces and RESTful conventions.

For developers with Django experience, this may be a review. But for complete beginners, these concepts are the critical prerequisites for understanding FastAPI's design philosophy. With this foundation in place, everything that follows — route definitions, request handling, data validation, and integration with SQLAlchemy 2.0 — will come much more naturally.