Getting Started with FastAPI: A Comprehensive Guide to Frontend-Backend Separation and RESTful API Core Concepts

Introduction

FastAPI is one of the fastest-running frameworks in the Python web framework ecosystem, purpose-built for modern frontend-backend separation architecture. For beginners just getting into web development, understanding the frontend-backend separation development pattern and RESTful API design specifications is the first step in learning FastAPI.

This article is based on the FastAPI tutorial by Bilibili creator Lao Xiao, systematically organizing the core concepts of web development patterns to help developers with zero background quickly establish the correct cognitive framework.

Two Modes of Web Development

Coupled Frontend-Backend Mode

The coupled (non-separated) frontend-backend approach is a relatively traditional development pattern. In this mode, everything the client browser sees—including the interface, effects, and data—is all provided by the same server.

The specific workflow is: the browser sends a request to the application server, the server queries the database to retrieve data, processes business logic, then renders the data into HTML templates, and finally returns a complete HTML page to the browser.

Typical representatives of this pattern include early PHP (such as WordPress, Laravel's Blade templates), Java's JSP/Servlet, Python's Django template system, etc. The server side uses a Template Engine to embed dynamic data into HTML markup, generating complete pages before returning them to the browser all at once. This approach is also known as SSR (Server-Side Rendering). Although now considered a "traditional" pattern, it still has advantages in SEO optimization and first-screen loading speed, which is why modern frameworks like Next.js and Nuxt.js have reintroduced server-side rendering concepts, forming what's called "isomorphic rendering" solutions.

The main problems with this pattern include:

• Developers need to handle interface code, business logic, and data processing simultaneously
• The frontend interface must be designed first before backend rendering development can proceed
• Development efficiency is low, making parallel development between frontend and backend teams impossible

Frontend-Backend Separation Mode (Mainstream)

Frontend-backend separation is the development pattern adopted by over 90% of enterprise-level projects today. Its core philosophy is splitting by technical responsibility:

• Frontend server (static file server): Dedicated to storing and serving static resources like HTML, CSS, JS, and images, responsible for interface display and interaction effects
• Backend server (Python application server): Dedicated to handling business logic and data operations, providing unified API endpoints externally, returning data in JSON format

The rise of frontend-backend separation is closely related to the popularization of AJAX technology. After Google Maps extensively used AJAX (Asynchronous JavaScript and XML) technology in 2005, browsers gained the ability to communicate asynchronously with servers without refreshing the page. Subsequently, the emergence of frontend frameworks like Angular (2010), React (2013), and Vue (2014) enabled the frontend to independently build complex Single Page Applications (SPA). The frontend is deployed via static file servers like Nginx, and at runtime calls backend APIs through HTTP requests to fetch data, which is then efficiently rendered by the frontend framework's virtual DOM mechanism. In this architecture, frontend and backend collaborate through API contracts (typically interface documentation), decoupled from each other.

The advantages of this architecture are very clear:

1. Parallel development: Frontend and backend teams can work simultaneously—as long as requirements are confirmed, each team can proceed independently
2. Clear responsibilities: The backend only handles data and logic; the frontend only handles display and interaction
3. Multi-platform reuse: The same set of backend APIs can simultaneously serve browsers, mobile apps, WeChat mini-programs, and other clients

The backend server doesn't care where the data is ultimately displayed—whether it's a browser, iOS/Android app, or mini-program. As long as the client sends a request, the backend returns JSON-formatted data. The client then decides how to display it.

FastAPI's Positioning and Features

FastAPI was designed for the frontend-backend separation pattern from its inception. It's built on top of the Starlette framework, making it naturally suited for API endpoint development.

Starlette is a lightweight ASGI (Asynchronous Server Gateway Interface) framework. ASGI is the asynchronous upgrade of WSGI (Web Server Gateway Interface)—WSGI is the traditional standard interface for Python web applications (both Django and Flask are based on WSGI), but it only supports synchronous processing and cannot efficiently handle WebSocket, long-polling, and similar scenarios. ASGI was proposed in 2018 by Andrew Godwin, the author of the Django Channels project, supporting asynchronous request processing and enabling Python web applications to leverage asyncio for high concurrency. FastAPI is built on top of Starlette, inheriting its high-performance asynchronous processing capabilities while adding type-hint-driven data validation (based on Pydantic) and automatic API documentation generation. This is the key reason why FastAPI can approach Node.js and Go language frameworks in performance benchmarks.

Of course, FastAPI also supports the coupled frontend-backend development approach—it can integrate the Jinja2 template engine for page rendering. But judging from the emphasis in the official documentation, FastAPI's core positioning is as a backend API development framework.

FastAPI's positioning can be summarized as follows:

• It's currently the fastest-running Python web backend framework
• Primarily used for backend development in frontend-backend separation projects
• Also has some frontend rendering capability (through template engines)
• Supports integration with ORM frameworks like SQLAlchemy 2.0

Regarding ORM (Object-Relational Mapping), it's a technology that maps objects in programming languages to database tables, allowing developers to operate databases in an object-oriented manner without writing raw SQL statements. SQLAlchemy is the most mature ORM framework in the Python ecosystem. Version 2.0, released in 2023, underwent a major refactoring, introducing entirely new declarative mapping syntax and native async support (via asyncio). The combination of FastAPI and SQLAlchemy 2.0 is particularly well-suited because both support Python's async/await asynchronous programming model, enabling database operations without blocking the event loop, thus fully leveraging FastAPI's high-concurrency advantages.

RESTful API Interface Specification

What is an API Interface

API (Application Programming Interface) is the entry point an application exposes for operating on data. This entry point can be a function, a class, or a URL address. Clients call these interfaces by sending HTTP requests to retrieve or manipulate data.

There are currently two mainstream API interface specifications on the market:

• RESTful: The most mainstream interface development specification currently, widely used
• RPC: Remote Procedure Call protocol, with relatively lower market share

RPC (Remote Procedure Call) is another mainstream API design paradigm. Unlike REST which is resource-oriented, RPC is action-oriented—clients call remote services as if calling local functions. Typical RPC frameworks include Google's gRPC (based on Protocol Buffers serialization), Apache Thrift, and Dubbo which is widely used in China. RPC typically uses binary protocols for data transmission, offering better performance than the text-based REST+JSON combination, making it more popular in microservice internal communication and high-performance computing scenarios. REST, due to its simplicity and universality, is more suitable for externally exposed public APIs. In actual enterprise architectures, a hybrid pattern of REST for external and RPC for internal communication is often adopted.

The Core Philosophy of RESTful

REST stands for Representational State Transfer. While the direct translation isn't very intuitive, its core philosophy is very clear: resource-oriented development.

The REST architectural style was first proposed by Roy Fielding in his 2000 doctoral dissertation. Fielding was one of the principal designers of the HTTP/1.1 protocol, and he summarized the successful architectural principles of the Web as REST. REST defines six architectural constraints: client-server separation, statelessness, cacheability, uniform interface, layered system, and code on demand (optional). Among these, "uniform interface" is REST's most core constraint, requiring standard HTTP methods to operate on resources, resources identified by URIs, and operation results communicated through HTTP status codes (e.g., 200 success, 201 created, 404 not found, 500 server error). It's worth noting that APIs strictly following all REST constraints are called RESTful APIs, while in practice many APIs are only "REST-like" in style without fully adhering to all constraints.

RESTful treats all API endpoints as operation entry points for "resources." Resources are data, URL paths represent the resources to be operated on, and HTTP methods represent the type of operation on the resource:

HTTP Method	Operation	Example URL	Description
POST	Create	/students	Add a student
GET	Read	/students	Get all students
GET	Read	/students/{id}	Get a specific student
PUT	Update	/students/{id}	Update a specific student
DELETE	Delete	/students/{id}	Delete a specific student

The advantages of this design include:

• Clear semantics: The operation type can be determined from the HTTP method alone
• Clean URLs: Paths only describe resources, not actions
• Higher security: Combined with HTTP method semantic constraints
• Cross-platform universality: Any client capable of sending HTTP requests can call the API

Why Choose JSON as the Data Format

In frontend-backend separation architecture, the data format returned by the backend is almost always JSON. Compared to the earlier XML format, JSON has the following advantages:

• Concise and lightweight: Smaller data size, higher transmission efficiency
• Cross-language support: Almost all programming languages have comprehensive JSON parsing libraries
• Easy to work with: Natively supported by frontend JavaScript, and Python also has a built-in module

JSON (JavaScript Object Notation) was proposed by Douglas Crockford in 2001, with syntax derived from JavaScript object literals. Compared to XML (eXtensible Markup Language), JSON doesn't have the redundant overhead of closing tags—for the same data, JSON is typically only 30%-50% the size of XML. For example, representing a student's information, XML requires <name>Zhang San</name>, while JSON only needs "name": "Zhang San". Additionally, JSON parsing speed is significantly faster than XML because XML requires building a DOM tree for parsing, while JSON can be directly mapped to dictionary/object structures in programming languages. Python's standard library json module can directly convert JSON strings to dict, and FastAPI goes further by implementing automatic JSON data validation and type conversion through Pydantic models.

Currently, over 95% of web applications, mobile apps, and desktop applications use JSON as their data exchange format, and XML has essentially exited the mainstream stage.

Summary

Before learning FastAPI, understanding these foundational concepts is crucial:

1. Frontend-backend separation is the mainstream pattern for current enterprise-level development
2. FastAPI is inherently designed for backend API development
3. RESTful is the most mainstream API interface design specification
4. JSON is the de facto standard for data exchange

With these concepts mastered, you've laid a solid foundation for diving deeper into FastAPI's core features like routing, request handling, and data validation.