FastAPI Beginner's Guide: Frontend-Backend Separation and Core API Design Concepts

FastAPI, one of the fastest technologies in the current Web framework landscape, is attracting increasing attention from backend developers. This beginner-friendly tutorial series by Bilibili creator Lao Xiao starts from Web development patterns and gradually dives into FastAPI itself and its integration with SQLAlchemy 2.0. Based on the core content of that tutorial, this article outlines the key concept groups you must master to get started with FastAPI.

Non-Separated Frontend and Backend: One Server Does It All

In Web development, non-separated frontend and backend is an older development pattern. The interface effects the browser sees, the data displayed in the interface, and the special effects that pop up when a button is clicked are all provided by the same application server. Internally, the server must write business logic code, data processing code, and interface rendering code all at once.

The pain point of this pattern is that interface design must be completed first; otherwise, the backend cannot embed data into the page for rendering, which greatly reduces development efficiency. Moreover, frontend and backend code are coupled together, making it impossible to split teams by technology. For FastAPI learners, you only need to understand this pattern; the focus should be on frontend-backend separation.

Frontend-Backend Separation: Split by Technology, Each Doing Its Job

Frontend-backend separation completely decouples the interface from the data. The frontend server specifically stores static files such as HTML, CSS, JS, and images, so it is often called a static file server; the Python application server focuses on handling business logic and returning data. The two are developed and deployed independently, and as long as requirements are confirmed, the frontend and backend teams can proceed in parallel. This is also the most popular development pattern for enterprise-level Web projects today, and the vast majority of projects adopt this architecture.

In the separated pattern, when the browser requests the interface, it accesses the frontend server; when it requests data, it accesses the Python application server. The data format returned by the backend is mainly JSON because it is concise, cross-language, and easy to work with. Whether it is a browser, a mobile app, or a WeChat Mini Program, all can uniformly consume the JSON data returned by the same set of APIs. The backend is only responsible for handling logic and providing data; where the data is ultimately displayed is decided by the client.

JSON (JavaScript Object Notation) is a lightweight text data interchange format that originated from JavaScript's object literal syntax but has become a language-independent standard (RFC 8259). It supports only six data types: objects, arrays, strings, numbers, booleans, and null. Its structure is concise and highly readable, and almost all programming languages either have built-in support or can quickly parse and generate JSON through libraries. Compared with XML, JSON is smaller and faster to parse, so it has replaced XML as the de facto mainstream data format in the Web API field. In a frontend-backend separation architecture, the backend serializes business data into JSON and returns it, and the frontend or client deserializes it and renders it for display, thereby decoupling the interface from the data.

FastAPI's Positioning: A Backend Framework Born for APIs

FastAPI is built on top of Starlette, and Starlette was designed from the start for API interface development. Therefore, FastAPI is naturally suited for frontend-backend separation projects and focuses on backend development. However, it can also support non-separated frontend-backend scenarios by integrating the Jinja2 template engine for interface rendering, though the official documentation still emphasizes API backend development.

Understanding frontend-backend separation is a prerequisite for understanding FastAPI's design philosophy. FastAPI's goal is to provide a unified API interface externally so that any client can obtain data as needed.

Starlette is a lightweight ASGI (Asynchronous Server Gateway Interface) framework/toolkit that provides foundational capabilities for Python asynchronous Web development, such as routing, middleware, request/response objects, WebSocket, and background tasks. ASGI is the next-generation Python Web server gateway interface standard after WSGI, supporting asynchronous coroutines and long-lived connections. FastAPI does not reimplement these underlying mechanisms; instead, it builds on Starlette and focuses on providing capabilities such as type-annotation-based parameter validation, dependency injection, and automatic OpenAPI documentation generation. Therefore, its performance and asynchronous features are largely inherited from Starlette.

Jinja2 is the most commonly used template engine in the Python ecosystem. It uses syntax similar to Django templates and embeds dynamic data into HTML templates through placeholders such as {{ variable }} and {% control statement %} to render the final page. FastAPI can integrate Jinja2 through Jinja2Templates, retaining API development capabilities while returning HTML responses, which is exactly why it can accommodate non-separated frontend-backend scenarios.

API Interfaces and the REST Specification

API (Application Programming Interface) is the entry point through which an application exposes data operations externally. It can be a function, a class, or a URL address. Currently, the mainstream API interface specifications are REST and RPC. RPC is an interface development protocol, while REST is more often called a development style and is essentially a set of human-agreed communication rules. REST currently dominates the market because it is convenient to use and relatively secure.

REST stands for Representational State Transfer. A direct Chinese translation is actually hard to understand, so just treat it as the name of a specification, just as ISO9001 is the name of a quality management system. REST is a resource-oriented programming pattern that treats all API interfaces as resources, and resources are data. When defining an interface, the URL path accessed by the client represents the data resource to be operated on.

RPC (Remote Procedure Call) is a protocol style that lets a client call functions on a remote server as if calling local functions. It emphasizes "actions" rather than "resources," and common implementations include gRPC, JSON-RPC, and XML-RPC. RPC interfaces are usually named with verbs (such as getUser and createOrder) and can strictly define parameters and return structures through an IDL (Interface Definition Language), making them suitable for high-performance communication between internal services. The core difference between REST and RPC lies in their abstraction perspective: REST is resource-centric, using URLs to identify resources and HTTP methods to express operations; RPC is process-centric, using method names to express behavior. Each has its applicable scenarios. REST is closer to HTTP semantics and more general, so it is more popular in externally exposed APIs.

Expressing Operation Semantics with Request Methods

In the REST style, different operations on the same resource are distinguished by request methods:

• Add a student: use a POST request with the path pointing to the student collection
• Get all students: use a GET request with the path pointing to the student collection
• Get a specific student: use a GET request with the student ID appended to the path
• Update a student: use a PUT or PATCH request with the student ID appended to the path
• Delete a student: use a DELETE request with the student ID appended to the path

The same resource path combined with different request methods forms a clear, semantically meaningful interface system. This is also a core idea that will be used repeatedly in FastAPI route design. Once you master these two concept groups—frontend-backend separation and REST resource modeling—moving on to FastAPI interface development, parameter validation, and asynchronous processing will be much smoother.

PUT and PATCH are both used to modify resources, but their semantics differ: PUT means completely replacing the target resource with the request body, so the client must submit all fields of the resource, and fields not submitted are usually set to empty or restored to default values; PATCH means partially updating the resource, so only the fields to be modified need to be submitted, and fields not mentioned remain unchanged. REST also emphasizes idempotency: GET, PUT, and DELETE are idempotent, meaning executing them multiple times has the same effect as executing them once; POST is usually non-idempotent, and repeated submissions may create multiple records. Understanding these semantics helps design interfaces with predictable behavior that are easy to cache and retry.

One-line Summary

Outlines the core concepts of frontend-backend separation, APIs, and REST essential for getting started with FastAPI

Paragraph Summary

Based on Bilibili creator Lao Xiao's FastAPI tutorial, this article outlines the key concept groups beginners must master. It first compares non-separated and separated frontend-backend Web development patterns, pointing out that the separated pattern splits static file servers and Python application servers by technology and is the current mainstream enterprise architecture, with the backend uniformly providing data externally as JSON. It then explains that FastAPI is built on Starlette and is naturally oriented toward API backend development, while also supporting template rendering through Jinja2. Finally, it introduces the meaning of API interfaces and the two specifications REST and RPC, focusing on REST's resource-oriented modeling approach and how to use request methods such as GET, POST, PUT, PATCH, and DELETE to express different operation semantics on the same resource path.