REST API（进行中）

Source: Dev.to

在上一集里，我们探讨了让数据在网络中流动的网络协议，例如用于可靠性的 TCP、用于请求的 HTTP/HTTPS，以及用于实时聊天的 WebSockets。在此基础上，第 3 集深入了解应用程序如何以更结构化的方式进行通信，首先从 API 开始。我们将首先关注 REST API，并使用日常类比来保持简洁。这为系列后续主题（如 gRPC、GraphQL 和通信模式）奠定了基础。
让我们从应用架构的基础以及 REST 的定位开始吧。

Source: …

层级的演进（餐厅类比）

要解释应用程序是如何构建的，可以把它想象成经营一家餐厅。我们将使用这个 数字厨房 的概念来拆解三种主要架构。

1‑层架构：餐车

所有操作都在同一个地点完成。接单的人同时也是厨师，还要从冰箱里取东西。

在软件中，这意味着 用户界面、业务逻辑和数据存储 都在同一台机器上——就像传统的桌面应用程序。

问题： 如果突然来了很多客人，整个系统会变慢甚至崩溃。你无法轻松添加帮助功能，除非重新开始。

2‑层架构：小餐馆

操作被划分为两个独立的空间：

• 前台柜台 – 顾客下单并与工作人员互动。
• 后厨 – 实际的工作在这里进行。

收银员专注于与顾客交谈、接受订单，可能会做一些轻量检查，例如“这是否是有效订单”，而后厨负责烹饪、定价规则、检查配料以及从冰箱取东西。

在软件层面：

• 客户端 – 处理用户界面和基本验证。
• 服务器 – 包含业务逻辑和数据库。

优势： 能够比餐车处理更多的顾客，因为多个客户端可以同时与同一个后厨通信，且对后厨的更改不一定需要重新构建前台。
缺点： 后厨承担了除接单之外的所有职责。随着菜单的扩展和顾客对定制选项的需求增加，所有这些特殊规则都会堆积在后厨，使其更难管理且响应速度变慢。要扩展存储或逻辑，需要重新设计整个后厨，因为逻辑和数据是放在一起的。

3‑层架构：高级餐厅

现在这家餐厅已经完全专业化，并且具备可扩展性。

• 表示层（前厅服务员） – 只专注于客人的体验，引导顾客浏览菜单并下单，而不需要了解食物的烹饪细节。
• 应用层（厨房大厨） – 纯粹负责烹饪和应用业务规则，独立于订单的获取方式。
• 数据层（储藏区） – 管理食材、配方和库存，独立于餐厅用餐区和厨房。

在软件中，这种分离意味着每一层只有单一职责，允许你在不重新设计整个系统的情况下，增加更多的服务员、厨师或更大的仓库。这样可以更轻松地应对业务增长、菜单变更或巨大的流量高峰。

什么是 API？什么是 REST？

在讨论 REST 之前，先来定义 API（应用程序编程接口）。在餐厅里，它就像服务员递给厨师的点单单。前端（服务员）写下所需的内容并交给后端（厨师）。服务员不需要了解烤箱是如何工作的；他们只需遵循格式。这是系统之间的一个简单契约，让它们在不了解彼此内部实现的情况下进行通信。

REST（表述性状态转移）是一种构建 API 的风格。如果说 API 是点单单，那么 REST 就是填写点单单的标准方式，使得每个人都使用相同的语言。

与随意的笔记不同，REST 使用一致的 名词 和 动词 通过 HTTP（参见第 2 集）。

• 名词（资源）： 如 /orders、/menu-items、/customers——也就是你 dea (原文被截断) 的东西。

动词（方法）

• GET – 获取某些内容
• POST – 创建新资源
• PUT – 更新资源
• DELETE – 删除资源

这使得 3‑层架构能够在互联网上顺畅运行，让前端轻松与后端对话。对于 prasunchakra.com，如果它有后端 API，你可能会使用 GET /posts 来获取博客数据。