FastAPI Lesson One: Understanding the Core Logic of Web Development

As one of the fastest web frameworks available today, FastAPI is quickly becoming the go-to choice for Python backend development. But before you write a single line of code, there are three concepts you can't ignore: web development patterns, API interfaces, and RESTful standards. This article, based on the FastAPI tutorial series by Bilibili creator 老肖, covers the foundational knowledge every beginner needs.

Monolithic (Non-Separated) Architecture: One Server Does It All

The most common early approach to web development was the "non-separated" (monolithic) model. Its defining characteristic: everything the user sees in the browser — the layout, effects, and displayed data — is served by a single server.

The flow looks like this: browser sends a request → the application server queries the database → processes business logic → fills data into an HTML template ("rendering") → returns the complete HTML page to the browser.

Historical Context: The non-separated model (also called Server-Side Rendering, or SSR) peaked in the 2000s, typified by PHP, JSP, and ASP.NET WebForms. The server completes all rendering before returning the page, and the browser receives a fully formed HTML document. The historical limitation of this model was that nearly every user interaction required a full page reload — expensive in bandwidth and poor in user experience. It wasn't until AJAX became widespread around 2005, enabling partial page updates, that the path to frontend-backend separation was cleared.

This model required developers to write business logic, data processing, and UI rendering code all within the same server, leading to low development efficiency — backend work couldn't proceed until frontend design was finalized, creating tight coupling between the two. This is the primary reason the model fell out of favor; today it's mostly understood as a historical reference point.

Frontend-Backend Separation: The Dominant Pattern for Enterprise Projects

Frontend-backend separation is the approach used by over 90% of enterprise-level web projects today. The key difference: at least two independent servers exist:

• Frontend server (static file server): Serves static assets like HTML, CSS, JavaScript, and images — responsible for UI, buttons, layout, and interactive effects.
• Python application server (backend server): Handles business logic and returns data.

This separation of responsibilities brings significant advantages: frontend and backend teams can develop in parallel. As long as the interface contract (API) is agreed upon upfront, neither team has to wait for the other, dramatically improving collaboration efficiency.

In a separated architecture, browser requests are also split: requests for UI go to the frontend server, requests for data go to the Python application server. Over 95% of data returned by backends today uses JSON format — compared to the once-popular XML, JSON is more concise, universally cross-language compatible, and easier to work with.

JSON vs. XML: The Evolution: JSON (JavaScript Object Notation) was proposed and popularized by Douglas Crockford in 2001, with syntax derived from JavaScript object literals. Compared to XML, JSON requires no closing tags, is typically 30–50% smaller, parses faster, and is natively supported by JavaScript. XML was widely used in SOAP protocols and early Web Services, but as REST-style APIs rose to prominence, JSON gradually became the de facto standard for internet data exchange.

It's worth emphasizing that backend servers don't just serve web pages. Mobile apps and WeChat Mini Programs are, at their core, just "interfaces" — the data they display also comes from backend responses. The backend's role is therefore very focused: handle logic and return data. What the client does with that data is none of the backend's concern.

FastAPI Is Built for Frontend-Backend Separation

Understanding these two patterns makes it clear why they matter — because FastAPI is a framework designed from the ground up for the frontend-backend separation model.

FastAPI is built on top of Starlette, which was purpose-built for API interface development from day one.

Starlette and ASGI: Starlette is a lightweight Python ASGI (Asynchronous Server Gateway Interface) framework released by Tom Christie in 2018. ASGI is the asynchronous successor to WSGI — WSGI is synchronous, consuming one thread per request; ASGI leverages Python's async/await syntax, allowing a single process to handle thousands of concurrent connections. FastAPI builds on Starlette to inherit its async capabilities, then layers on Pydantic's data validation and type annotations, delivering exceptional developer experience without sacrificing performance.

Of course, FastAPI can also integrate with the Jinja2 template engine for server-side rendering, supporting non-separated projects. But according to the official documentation, its core positioning remains backend API development. In short, FastAPI is the fastest Python backend service framework, focused on backend development with some frontend rendering capability as a bonus.

What Is an API Interface?

API stands for Application Programming Interface — simply put, it's an entry point that an application exposes for external access to its data.

This entry point can be a function, a class, or a URL. Clients that want to call it simply send a request. The vast majority of backend projects on the market today are implemented as API interfaces.

There are two mainstream API interface standards: REST and RPC.

The Core Difference Between REST and RPC: REST (Representational State Transfer) was proposed by Roy Fielding in his 2000 doctoral dissertation, emphasizing constraints like "statelessness," "uniform interface," and "resource orientation." RPC (Remote Procedure Call) abstracts remote operations as local function calls; notable implementations include gRPC (Google), Thrift (Facebook), and Dubbo (Alibaba). RPC typically uses binary protocols (such as Protobuf) and excels at performance in microservice-to-microservice communication; REST, based on HTTP + JSON, is far more friendly to browsers and third-party clients, making it dominant in public-facing API design.

RPC is an interface development protocol that Python can also implement, but it holds a smaller market share. REST is better understood as a "development style" or convention, and it's the overwhelming standard today — because it's convenient and offers relatively strong security.

RESTful Standards: Resource-Oriented API Design

REST stands for Representational State Transfer. Don't get too hung up on the literal translation — think of it as the name of an internationally recognized API design convention, much like how quality management systems are named ISO 9001.

The core of REST is resource-oriented programming. It treats every API interface as a kind of "resource," and resources are fundamentally data. This philosophy holds that the job of backend development is to provide access interfaces to data resources. Therefore, when defining interfaces, the URL path represents the data resource being operated on, while different operations on the same resource are distinguished by different HTTP request methods:

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

The Semantic Conventions of HTTP Methods: The HTTP/1.1 protocol defines multiple request methods, and RESTful standards assign them clear semantics: GET is for reading resources (idempotent and safe); POST is for creating new resources (non-idempotent); PUT is for fully replacing a resource (idempotent); PATCH is for partial updates; DELETE is for removing resources (idempotent). "Idempotency" means that making the same request multiple times yields the same result as making it once — critical for network retry mechanisms. Following these semantic conventions not only makes APIs more readable, but also allows infrastructure like CDN caching and API gateways to make correct processing decisions.

Through this design, operations on the same "student" resource can clearly express the intent of each CRUD operation using nothing more than a combination of HTTP method and URL path. This is exactly what makes RESTful design elegantly simple.

Summary

This article didn't jump straight into code. Instead, it laid three foundational stones:

• Web development patterns: Non-separated architecture is history; frontend-backend separation is the enterprise standard.
• API interfaces: The data entry point an application exposes to the outside world — the core of backend development.
• RESTful standards: Resource-centered design, using URLs to represent resources and HTTP methods to express intent.

With these concepts in place, learning FastAPI's syntax and real-world usage (including later integration with SQLAlchemy 2.0) becomes far more meaningful — you'll understand not just what to do, but why, and avoid many common pitfalls.