当你与网站或应用进行交互时，潜藏在那些交互后面的过程非常复杂。这些过程的核心之一就是浏览器或应用是如何与服务器通信的。HTTP 方法定义了需要执行的操作——它可能是获取数据、发送信息或更改现有内容。

每种方法都有特定的用途，以保持网络通信的清晰、安全和有序。

在本文中，我们将分解最常见的 HTTP 方法，并解释它们如何运行以实现顺畅的在线互动。

目录

1. GET 方法

2. POST 方法

3. PUT 方法

4. PATCH 方法

5. DELETE 方法

6. HEAD 方法

7. OPTIONS 方法

8. TRACE 方法

9. CONNECT 方法

10. 总结

GET 方法

GET 方法是最常见的 HTTP 方法之一，用于从服务器请求数据。可以把它看作是索取信息而不做任何改变。

当你访问网页时，浏览器发送一个 GET 请求给服务器，要求页面的内容。然后服务器响应数据（如 HTML、图像或其他文件），浏览器进行显示。

关于 GET 的一个重点是它不会对数据进行任何更改。它只是“读取”或检索信息。例如，当你浏览社交媒体或在线搜索产品时，应用或网站使用 GET 来显示数据而不更改它。

另一个关键点是 GET 请求的参数通过URL传递，这意味着请求的数据会显示在浏览器的地址栏中。例如，如果你在网店搜索产品，搜索词会包含在 URL 中。

GET 请求示例

以下是使用 Fetch API 的 JavaScript 中一个简单的 GET 请求示例：

fetch('https://api.example.com/products?category=shoes')
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

在这个例子中，GET 请求被发送到 URL https://api.example.com/products ，带有查询参数 category=shoes，请求服务器返回鞋子类别的产品。

GET 方法的使用场景

GET 主要用于获取信息，以下是一些常见的应用场景：

1. 加载网页：每当你在浏览器中输入 URL 或点击链接时，就是在进行 GET 请求。浏览器向服务器请求网页，服务器返回显示内容。

   • 示例：GET /index.html HTTP/1.1

2. 从 API 获取数据：开发者常使用 API（应用程序接口）从外部服务器获取数据。例如，天气应用使用 GET 请求从天气 API 获取当前温度。

   • 示例：

   fetch('https://api.weather.com/current?city=Lagos')
      .then(response => response.json())
      .then(data => console.log(data));
   

3. 搜索查询：当你在 Google 或其他搜索引擎中进行搜索时会发出 GET 请求。你输入的搜索词包含在 URL 中，服务器返回匹配结果的列表。

   • 示例：GET /search?q=JavaScript

4. 检索文件：无论你是下载图片、查看 PDF 或播放视频，GET 都用于从服务器获取这些文件。

   • 示例：GET /files/image.jpg

GET 请求的最佳实践

要有效地使用 GET 请求，遵循一些良好的实践以确保数据处理的顺畅和安全是很重要的：

1. 仅用 GET 来检索数据：GET 请求用于获取数据，而不是发送如密码或个人数据等敏感信息。因为 GET 请求中的参数包含在 URL 中，任何人都可以看到它们。例如，如果你网站登录时，不应该使用 GET 发送密码，因为它会出现在 URL 中。

   • 不该做的示例：

   fetch('https://example.com/login?username=john&password=secret');
   

2. 保持 URL 简洁：由于 GET 请求的数据包含在 URL 中，过长的 URL 会造成问题。浏览器和服务器对于 GET 请求 URL 的数据量也有限制，所以避免放入太多信息。如果需要发送大量数据，考虑改用 POST 请求。

3. 为性能启用缓存：GET 请求通常会被浏览器缓存，即浏览器可以存储响应并无需再次联系服务器就重复使用。这提高了性能，尤其是对于不经常更改的静态内容，如图像或样式表。为此，确保服务器发送适当的 cache-control 头，以便可频繁请求的数据可以更快加载。

   • 设置缓存头的示例：

    Cache-Control: max-age=3600

4. 避免使用 GET 请求执行会修改数据的操作：由于 GET 是一种“安全”的方法，它仅应用于不会修改数据的操作。如果你想创建、更新或删除数据，应使用像 POST、PUT 或 DELETE 这样的方法。例如，如果你不小心使用 GET 来删除资源，可能会有人通过点击链接或刷新页面来删除它，这样做是不安全的。

   • 不要使用 GET 来进行删除操作的示例：

    GET /delete/user/123

5. 谨慎处理敏感数据：由于 GET 请求是 URL 的一部分，它们可能被记录或者保存在浏览器的历史记录中。避免在 GET 请求中发送敏感信息，如密码、信用卡详细信息或隐私数据。处理此类信息时应始终使用 POST 方法，以确保信息保持隐藏。

POST 方法

POST 方法用于向服务器发送数据。与仅用于获取数据的 GET 方法不同，POST 方法可以用来提交服务器可以处理或存储的信息。POST 方法通常用于用户输入数据的表单，如用户名、密码或联系信息。

当发出 POST 请求时，数据通过请求体（而非 URL）发送的。这样 POST 方法就成了发送更大或更敏感的信息（如密码）的理想选择，因为数据是隐藏的，不会出现在浏览器的地址栏中。

例如，当你注册一个网站或在博客上提交评论时，使用 POST 方法将你的信息发送到服务器，后者处理并将其存储在数据库中。

POST 请求示例

以下是使用 Fetch API 将表单数据发送到服务器的 POST 请求示例：

const formData = {
  username: 'john_doe',
  password: 'mypassword123'
};

fetch('https://example.com/login', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(formData)
})
.then(response => response.json())
.then(data => console.log('Success:', data))
.catch(error => console.error('Error:', error));

在这个例子中，POST 请求以 JSON 数据的形式在请求体中发送 username 和 password，这是一种安全地处理像密码这样的敏感信息的方法。

GET 和 POST 的差异

虽然 GET 和 POST 都用于与服务器通信，但它们的目的不同，处理数据的方式也不同：

数据传输：

• GET：数据包含在 URL 中，使其在地址栏中可见。这限制了可发送的数据量。

• POST：数据是在请求体中发送的，允许发送更多的信息。这也使得敏感信息不在 URL 中暴露。

目的：

• GET：用于获取数据。不会在服务器上改变或修改任何内容。

• POST：用于发送可能会改变或增加服务器资源的数据，比如向数据库添加新用户或提交表单。

缓存：

• GET：GET 请求可以缓存。因此浏览器可能会保存响应，从而加快后续请求。

• POST：POST 请求不会被缓存，因为它们通常涉及新的或更新的数据，这些数据不应重复使用。

幂等性：

• GET：多次发送相同的 GET 请求不会改变结果。每次都会返回相同的数据。

• POST：多次发送相同的 POST 请求可能会导致不同的结果。例如，提交表单两次可能会创建重复的条目。

POST 的常见使用场景

POST 是在需要向服务器发送数据时的理想选择，通常用于处理或存储。以下是一些常见的使用案例：

1. 提交表单：每当你在线填写并提交表单时，如注册新闻简讯或在注册表单中输入你的详细信息，POST 方法用于将该信息发送到服务器。服务器会处理数据，将其存储或根据需要执行其他操作。

   • 示例：

    <form action="https://example.com/register" method="POST">
      <input type="text" name="username" />
      <input type="password" name="password" />
      <button type="submit">Sign Up</button>
    </form>

2. 用户身份验证：当你使用用户名和密码登录网站时，通常使用 POST 将你的凭据安全地发送到服务器。服务器检查信息，如果凭据匹配，则授权访问你的账户。

3. 上传文件：POST 也用于上传文件，如图像、文档或视频。由于 POST 方法允许发送大量数据，它非常适合上传需要被处理或存储在服务器上的文件。

   • 使用表单上传文件的示例：

    <form action="https://example.com/upload" method="POST" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload File</button>
    </form>

4. 创建新资源：POST 经常在 API 中用于创建新资源。例如，当你向在线商店添加新产品时，POST 方法会被用来将产品详细信息发送到服务器，后者会将产品添加到商店的数据库中。

   • 发送产品数据的示例：

    const product = {
      name: 'New Sneakers',
      price: 59.99,
      category: 'Footwear'
    };

5. 向 API 发送数据：当需要发送将被处理或存储的数据时，POST 在 API 中被广泛使用。例如，一个记录你的健身进度的应用可能会使用 POST 将你的锻炼细节发送到服务器，在那里它会被存储和分析。

6. 在线购物：当你进行在线购物时，POST 用于将支付详情发送到服务器进行处理。服务器处理交易并用你的订单信息更新系统。

PUT 方法

PUT 方法用于更新或替换服务器上的现有资源。它将数据发送到服务器，并指示创建一个新的资源（如果不存在）或替换当前的资源。PUT 的关键思想是你告诉服务器资源应该是什么样的。

例如，想象一个网站上的用户资料。如果你使用 PUT 更新你的资料，服务器将用你提供的新数据替换整个资料。资料的每个部分都会完全匹配你发送的内容，因此如果某些信息缺失，它们将被新数据覆盖。

PUT 请求示例

下面是一个使用 Fetch API 更新用户数据的 PUT 请求示例：

const updatedProfile = {
  username: 'john_doe_updated',
  email: 'john_updated@example.com',
  age: 30
};

fetch('https://example.com/users/123', {
  method: 'PUT',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(updatedProfile)
})
.then(response => response.json())
.then(data => console.log('Updated:', data))
.catch(error => console.error('Error:', error));

在此示例中，PUT 请求使用新数据更新用户资料。资料将被 username、email 和 age 的值替换。如果某些数据缺失，例如 phoneNumber，它将从资料中删除。

何时使用 PUT

PUT 主要用于当你希望使用特定的完整数据更新或替换资源时。以下是一些使用 PUT 的常见情形：

1. 更新资源：当你需要对现有资源进行更改时，PUT 用于发送整个资源的新版本。例如，更新博客文章、产品详情或用户信息需要使用 PUT 完整替换资源。

   • 示例：

    const updatedPost = {
      title: 'New Title for My Blog',
      content: 'Updated blog content here...',
      author: 'John Doe'
    };

    fetch('https://example.com/blog/45', {
      method: 'PUT',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(updatedPost)
    });

2. 创建资源（如果不存在）：如果你发送一个 PUT 请求到一个尚无资源的特定 URL，服务器将使用你提供的数据创建一个。这在需要预先完全定义的资源时非常有用。

   • 如果产品不存在，创建产品的示例：

    const newProduct = {
      id: 101,
      name: 'New Sneakers',
      price: 59.99,
      category: 'Footwear'
    };

    fetch('https://example.com/products/101', {
      method: 'PUT',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(newProduct)
    });

3. 与 API 协作：在与 API 交互时，当你需要更新资源如用户资料、产品详情或任何其他结构化数据时，通常使用 PUT。例如，一个待办事项应用可能允许你使用 PUT 更新现有任务的新信息。

   • 更新任务的示例：

    const updatedTask = {
      title: 'Updated Task Title',
      completed: true
    };

    fetch('https://example.com/tasks/67', {
      method: 'PUT',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(updatedTask)
    });

PUT vs. POST：关键区别

虽然 PUT 和 POST 都可以向服务器发送数据，但它们有不同的目的和行为：

目的

• PUT：主要用于更新或替换现有资源。如果资源不存在，PUT 也可以创建它。

• POST：主要用于创建新资源或提交需要处理的数据。POST 不替换现有资源，而是添加新的。

数据处理

• PUT：用新数据替换整个资源。如果请求中缺少部分资源，该部分将被删除或替换。

• POST：添加或更新资源而不替换整个资源。例如，提交表单时，POST 向服务器添加新数据而不删除已有内容。

幂等性

• PUT：是幂等的，因此多次发送相同的 PUT 请求将始终产生相同的结果。无论你使用 PUT 更新资源多少次，结果都是一样的。

• POST：不是幂等的，因此多次提交相同的 POST 请求可能会创建重复的资源或产生不同的结果。

• PUT: 最适用于资源的更新和完全替换。例如，如果您要更新在线商店中的产品详情，PUT 确保您发送的所有细节都被新的替换。

• POST: 用于创建新条目或发送需要处理的数据。例如，提交在线订单或填写联系表单时使用 POST。

PATCH 方法

PATCH 方法用于对服务器上的资源进行部分更新。与完全替换整个资源的 PUT 方法不同，PATCH 允许您在不再发送完整数据的情况下更新资源的特定部分。这使得 PATCH 非常适合于只需调整某些细节而不影响资源的其他部分的场景。

例如，如果您有一个用户资料，只想更新电话号码，PATCH 使您可以仅发送新的电话号码，而其他部分资料保持不变。这种方式更高效，并减少了意外数据丢失的风险。

使用 PATCH 进行部分更新

PATCH 旨在对资源进行有针对性的更改。其工作原理如下：

• 有针对性的更改：当您使用 PATCH 时，您只需指定要更新的字段。例如，如果用户更新他们的邮箱地址，您仅需发送一个包含新邮箱的 PATCH 请求，服务器上的所有其他信息将保持不变。

• 效率：PATCH 比 PUT 更高效，因为它允许您仅发送正在更改的数据。对于只需修改一小部分的大型资源而言，这可以减少带宽使用。

• 不覆盖：与 PUT 不同，PATCH 不会替换整个资源。它只更新请求中提供的字段，保证其他字段不受影响。

PATCH 请求示例

以下是一个使用 PATCH 方法更新特定字段的基本示例，例如更改用户的邮箱地址：

const updatedEmail = {
  email: 'new_email@example.com'
};

fetch('https://example.com/users/123', {
  method: 'PATCH',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(updatedEmail)
})
.then(response => response.json())
.then(data => console.log('Email updated:', data))
.catch(error => console.error('Error:', error));

在这个例子中，只有 email 字段被更新。用户资料的其他部分，比如用户名或地址则保持不变。

何时使用 PATCH 而非 PUT

在特定情况下，使用 PATCH 比 PUT 更合适：

1. 更新特定字段：如果您只需要更新资源的一部分，比如更改用户的邮箱地址、为博客文章添加标签或修改单个属性，使用 PATCH 更好。它允许您仅发送需要更新的字段，使请求更高效。

   • 示例：更新用户的电话号码。

    const updatedPhone = { phoneNumber: '123-456-7890' };

    fetch('https://example.com/users/123', {
      method: 'PATCH',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(updatedPhone)
    });

2. 避免意外的数据丢失：使用 PUT 时，若遗漏任何字段，可能导致服务器删除或覆盖这些字段。PATCH 通过仅更新提供的特定字段，避免了此风险，确保没有意外的数据丢失。

   • 示例：如果您只想更新用户的用户名，而不想覆盖其他字段（如地址或偏好），PATCH 可以确保仅更新用户名。

3. 性能考量：PATCH 对于大型资源更为高效。例如，如果您管理一个拥有大量记录的数据库，并且需要更改其中的一小部分内容，PATCH 会减少发送到服务器的数据量，提高性能并加速过程。

   • 示例：更新大型订单的状态而不修改整个订单详情。

    const updatedStatus = { status: 'shipped' };

    fetch('https://example.com/orders/987', {
      method: 'PATCH',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(updatedStatus)
    });

4. 频繁更新：在数据经常变化的应用程序中，PATCH 使得仅更新资源的特定部分更加容易，而不影响整个结构。例如，在电子商务平台中，用户可能会经常更新他们的送货地址或支付方式，PATCH 能够处理这些频繁的变化，而无需重新发送整个用户资料。

   • 示例：更新订单的送货地址。

    const updatedAddress = {
      shippingAddress: '123 New Street, New City, Country'
    };

    fetch('https://example.com/orders/987', {
      method: 'PATCH',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(updatedAddress)
    });

PUT 和 PATCH 的关键区别

以下是 PATCH 和 PUT 的快速对比，这些对比项可以明确每种方法什么时候使用更合适：

PATCH 方法在您希望进行部分更新、避免覆盖其他数据并提高请求效率时特别有用。

DELETE 方法

DELETE 方法用于从服务器中移除资源。当发出 DELETE 请求时，服务器会删除指定的资源，这意味着该资源将不再可访问或可用。此方法常用于删除用户账号、从在线商店移除产品或清除数据库中过期的数据等任务。

与 GET 或 POST 不同，DELETE 不需要在请求中发送 body——只需提供要删除资源的 URL 就足够了。例如，要删除一个特定的博客文章，可以向该文章的 URL 发送 DELETE 请求，服务器将负责将其删除。

DELETE 的工作原理

要删除某个资源，通常只需提供要移除资源的 URL。不同于 POST 或 PUT 请求，DELETE 请求通常不需要 body。

示例

如果您想删除特定的一篇博客文章，可以向其 URL 发送 DELETE 请求：

fetch('https://example.com/posts/123', {
  method: 'DELETE'
})
.then(response => response.json())
.then(data => console.log('Resource deleted:', data))
.catch(error => console.error('Error:', error));

这将告诉服务器移除 ID 为 123 的博客文章。

安全使用 DELETE

DELETE 请求可能带来显著影响，因此需要谨慎使用以避免意外删除有价值的数据。以下是安全处理 DELETE 请求的一些关键考虑：

• 永久性操作：一旦 DELETE 请求被处理，资源通常就消失了。在某些情况下，系统可能实现“软删除”功能，其中资源被隐藏但并未完全移除。然而，大多数情况下使用的是“硬删除”，即完全擦除资源。软删除对恢复很有帮助，允许在需要时恢复数据。

• 认证：DELETE 请求应仅限于授权用户。执行 DELETE 操作前，服务器应验证用户有权限删除资源。例如，只有用户账号的所有者才能删除账号，而不是其他用户。

• 确认：许多应用程序在处理 DELETE 操作前会提示用户确认意图。此额外步骤可确保用户不会意外删除重要数据，尤其是诸如账户删除等不可逆的操作。

确认步骤示例：

if (confirm("Are you sure you want to delete this post?")) {
  fetch('https://example.com/posts/123', {
    method: 'DELETE'
  })
  .then(response => console.log('Post deleted'))
  .catch(error => console.error('Error:', error));
}

• 可逆性（软删除）：对于重要数据，通常使用软删除是比较好的，它不会完全移除数据，而是在数据库中标记为已删除。这使得在需要时数据可以恢复。例如，许多电子邮件系统会将已删除的邮件保留在“垃圾箱”文件夹中，直到它们被永久删除。

处理 DELETE 请求的最佳实践

1. 需要认证：只有经过认证的用户才能执行 DELETE 操作。这能防止未经授权的用户删除他们不拥有的资源。例如，用户只能删除他们自己的数据，而不能删除他人的数据。

   • 示例：在内容管理系统（CMS）中，确保只有文章的作者或管理员才能删除它。

2. 使用确认步骤：对于关键操作，确认用户的意图后再继续。这对于无法撤销的操作尤为重要，比如删除账户或永久移除文件。

   • 示例：显示一个提示，如“您确定要删除您的账户吗？此操作无法撤销。”

3. 记录删除操作：保留 DELETE 请求的记录，包括谁发起了请求以及何时发生。记录对责任、故障排除和在意外删除时的数据恢复非常重要。

   • 示例：在电商系统中，当产品从目录中移除时，记录发起请求的用户及删除时间等详细信息。

4. 对关键数据使用软删除：为可能需要恢复的数据实现软删除机制。这在诸如用户账户等场景中特别有用，因为用户可能在删除后希望恢复他们的数据。

   • 示例：当用户“删除”他们的账户时，将其标记为不活跃或隐藏，而不是完全擦除，允许用户在后续恢复。

5. 优雅地处理错误：如果 DELETE 请求失败，服务器应返回适当的错误信息。例如，如果资源不存在或用户无权删除它，服务器应响应“资源未找到”或“未授权操作”等信息。

   • 示例：对不存在用户的 DELETE 请求可能返回 404 Not Found 响应。

6. 仔细检查 URL 目标：在发送 DELETE 请求之前，确保 URL 指向正确的资源。错误地指向错误的资源可能导致意外的数据丢失。

   • 示例：如果您正在管理一个待办事项列表并想删除单个任务，确保 URL 特别指向该任务而不是整个列表。

7. 将结果告知用户：在成功的 DELETE 请求之后，通知用户资源已被删除。可以通过消息或通知确认操作。

   • 示例：在产品或文章从系统中移除后，显示“项目成功删除”之类的消息。

通常，一个成功的 DELETE 请求会返回以下状态代码之一：

• 200 OK: 表示删除成功，并包含响应主体（例如，确认删除的消息）。

• 204 No Content: 请求成功，但响应主体中没有返回内容。这在资源删除后非常常见，因为没有内容需要返回。

• 404 Not Found: 表示要删除的资源不存在。

DELETE 请求响应示例

如果 DELETE 请求成功且资源已移除，服务器可能会返回一个 204 No Content 状态：

HTTP/1.1 204 No Content

这个响应告诉客户端资源已成功删除，但不会返回任何额外数据。

HEAD 方法

HEAD 方法与 GET 方法类似，但有一个关键区别：它仅检索资源的头信息，而不是实际内容。

当你发送一个 HEAD 请求时，服务器会回应与 GET 请求相同的头信息，但不发送资源主体（如文本、图片或文件）。这使得 HEAD 很适合在不下载整个内容的情况下检查资源的信息，例如其大小或最后修改日期。

例如，如果你正在管理一个大文件并想在下载前检查其大小，可以使用 HEAD 请求从服务器获取此信息，而无需实际获取文件。

HEAD 与 GET 的比较

• 相同的头信息，无内容: HEAD 请求提供与 GET 请求相同的头信息，如 Content-Type、Content-Length、Last-Modified 等。然而，响应不包含主体——仅包含元数据。

• 请求更快: 由于不包含主体，HEAD 请求比 GET 请求更快并且消耗的带宽更少。这在你只对资源的细节而非内容感兴趣时特别有用。

HEAD 的使用场景

1. 检查资源可用性: 你可以使用 HEAD 请求检查资源（如网页或文件）是否存在而不获取内容。例如，如果 URL 返回状态代码为 200 OK，你就知道资源存在。404 Not Found 状态代码则表示它不可用。

2. 测试链接: 如果你管理的网站有大量外部链接，可以用 HEAD 请求测试这些链接是否仍然有效，而无需加载整个页面。如果 HEAD 请求返回错误代码，你就知道链接已断开。

3. 获取文件元数据: 如果你在处理大文件，可能需要在下载前检查它们的大小。HEAD 请求允许你收集元数据，如文件大小 (Content-Length) 和类型 (Content-Type)，而不提取整个文件。

4. 优化缓存: 浏览器和应用程序可以使用 HEAD 请求检查资源自缓存以来是否已更新。服务器返回如 Last-Modified 或 ETag 这类头信息，如果这些值未改变，则可以使用缓存版本，从而节省带宽和时间。

5. API 效率: 当客户端需要验证数据是否存在而不下载整个响应时，HEAD 请求在 API 中很有用。例如，请求可以检查数据库中是否存在记录而无需获取完整细节。

6. 服务器健康监控: HEAD 请求可以用来测量服务器性能。通过测试响应速度而不下载内容，开发者可以监控服务器响应时间、检查问题或确定服务器是否正常运行。

使用 HEAD 的最佳实践

• 高效测试: HEAD 非常适合验证资源或测试 API 端点，而不下载不必要的数据。

• 缓存验证: HEAD 请求有助于缓存验证，确保资源是最新的，而不消耗带宽。

• 无副作用: 像 GET 一样，HEAD 应该是安全且幂等的，即不应改变资源的状态。它纯粹用于检索信息。

OPTIONS 方法

OPTIONS 方法用于查明对特定资源允许哪些操作。它允许客户端（如浏览器或 API）向服务器询问，“我可以对这个资源执行什么操作？” 服务器则会列出它对该资源支持的 HTTP 方法，如 GET、POST、PUT、DELETE 等。

OPTIONS 不会对资源本身执行任何操作。相反，它提供有关客户端可以执行什么操作的信息。这在你想检查允许哪些操作而不实际提出改变或检索数据的请求时很有用。

例如，如果你正在使用 API 并想查看它是否在特定端点支持 DELETE 方法，可以发送 OPTIONS 请求以获取该信息，而不影响资源。

检索目标资源支持HTTP请求的方法

1. 发送 OPTIONS 请求：客户端向服务器发送 OPTIONS 请求，通常针对特定 URL。该请求用作关于允许对该端点上的资源执行什么操作的查询。

2. 服务器的响应：服务器通过 Allow 响应头返回该资源支持的 HTTP 方法。例如，可能返回 Allow: GET, POST, DELETE，表示可以使用这些方法。

3. 测试方法: 如果不确定服务器是否支持特定方法（如 PATCH 或 DELETE），可以先发送 OPTIONS 请求进行检查。这可以避免尝试服务器不支持的方法，从而避免错误。

OPTIONS /api/resource HTTP/1.1
Host: example.com

服务器响应：

HTTP/1.1 200 OK
Allow: GET, POST, DELETE

OPTIONS 方法在跨域资源共享（CORS）中的使用

OPTIONS 方法最常见的用途之一是在处理**跨域资源共享（CORS）**时。CORS 是一种安全特性，保证一个域名上的资源不会被另一个域名的网页不当访问。

CORS 和预检请求

当浏览器需要进行跨域请求（例如，从domainA.com请求到api.domainB.com），浏览器首先会向目标服务器发送一个被称为预检请求的OPTIONS 请求。预检请求用于检查实际请求是否符合服务器的 CORS 策略。

1. 预检请求：浏览器在实际请求（如 POST 或 PUT）前发送一个 OPTIONS 请求。该请求询问服务器允许哪些方法、哪些域名可以访问资源，以及是否允许特定的头信息或凭据。

2. 服务器响应：服务器用 CORS 头信息回应，例如 Access-Control-Allow-Methods、Access-Control-Allow-Origin 和 Access-Control-Allow-Headers。这些信息告知浏览器该请求是否可以继续、允许哪些方法或域名。

   示例响应：

   HTTP/1.1 204 No Content
   Access-Control-Allow-Origin: https://domainA.com
   Access-Control-Allow-Methods: GET, POST
   Access-Control-Allow-Headers: Content-Type
   

3. 确保安全性：CORS 和预检 OPTIONS 请求确保只有在服务器许可的情况下才允许跨域请求。如果没有此安全步骤，网站可能会对其他域名进行未经授权的请求。

4. 处理复杂请求：如果请求包含自定义头信息、使用非简单 HTTP 方法（如 GET 或 POST）或发送诸如 cookies 的凭据，浏览器会自动发送 OPTIONS 预检请求。如果服务器拒绝请求（即返回头信息不允许该操作），浏览器会拦截请求。

简化的工作流程

• 浏览器： "我可以向[api.domainB.com]请求吗？"

• 服务器： "可以，你可以使用 GET 和 POST，但只能从[domainA.com]并且使用这些头信息。"

• 浏览器： 如果响应允许，则继续实际请求。

OPTIONS 方法的使用场景

• 发现可用方法：对于开发者来说有用，可以在进行操作之前检查一个资源支持哪些 HTTP 方法。

• CORS 预检：在网络安全中至关重要，确保跨域请求是经过适当授权的。

• 提高 API 效率：API 可以通过 OPTIONS 公开一个资源支持的方法，使客户端更容易理解可以执行哪些操作。

因此，OPTIONS 方法在管理请求权限和提高安全性方面对网络应用程序是必不可少的，特别是在跨域场景中。

TRACE 方法

TRACE 方法用于调试网络应用程序和测试请求如何通过网络。当你发送一个 TRACE 请求时，会触发一个回环测试，服务器将原样返回它接收到的请求。这有助于开发者查看请求在通过不同系统（如防火墙或代理）到达服务器前是否被修改。

简单来说，TRACE 允许你追踪请求从客户端（如浏览器或 API 工具）到服务器再返回的路径。这种方法对于识别请求传输过程中的问题很有用。

理解回环测试

回环测试指的是通过 TRACE 查看请求在跨网络时如何处理，以检查原始请求是否保持完整。具体如下：

1. 发送 TRACE 请求：你向服务器发送一个 TRACE 请求。这个请求通常较小，包含基本信息如方法、URL 和头信息。它不像 POST 或 PUT 方法那样携带额外数据或负载。

2. 服务器响应：服务器不是以资源作为响应，而是逐字返回它接收到的请求。这包括 HTTP 方法、URL、头信息和原始请求中的其他内容。服务器不修改或处理请求，只是原样返回。

3. 追踪路径：当 TRACE 响应返回时，你可以看到请求经过的完整路径，包括请求头信息或内容中的任何变化。对以下问题的诊断特别有用：

   • 代理服务器：如果你的请求在到达目的地之前经过一个或多个代理服务器，TRACE 可以显示这些代理是否更改了请求头信息或内容。

   • 网络防火墙：某些网络防火墙可能在请求经过时添加或修改头信息。TRACE 可以揭示这些修改。

   • 错误跟踪：如果请求未按预期运行，TRACE 可以帮助追踪传输过程中出现问题的地方。

4. 有效调试：TRACE 在调试网络应用程序或 API 特别有帮助。如果你的应用程序因路由、代理或服务器配置引发错误，TRACE 让你看到未修改的请求，从而更容易定位问题。

TRACE 的安全问题

虽然 TRACE 在调试中很有用，但通常被视为安全风险，并且由于多个原因在大多数服务器上经常被禁用：

1. 跨站脚本攻击 (XSS)：TRACE 方法可能会暴露请求头中的敏感信息，如 Cookie 或认证令牌。恶意行为者可能利用 TRACE 来捕获这些详细信息，导致安全漏洞，特别是在存在跨站脚本攻击 (XSS) 等漏洞时。这使 TRACE 成为攻击者试图窃取用户数据的潜在目标。

2. 请求修改暴露：由于 TRACE 显示了对请求所做的所有修改，它还可以揭示内部代理和防火墙如何处理请求。这可能让攻击者深入了解网络内部运作，为他们策划进一步攻击提供便利。

3. 出于安全目的禁用 TRACE：基于这些原因，TRACE 通常在大多数网络服务器上被禁用以防滥用。在许多现代 Web 应用程序中，存在更为安全的方法用于调试请求和追踪网络路径，因此在日常使用中 TRACE 很少必要。

4. 更安全的替代方案：开发人员可以使用现代 Web 框架和 API 内置的更安全的诊断工具和日志功能。这些替代方案能提供类似的见解而不会带来 TRACE 相关的安全风险。

CONNECT 方法

CONNECT 方法主要用于通过中介（通常是代理服务器）在客户端和服务器之间建立隧道。当客户端发送 CONNECT 请求时，服务器创建一个隧道，允许加密数据在客户端和目标服务器之间流动。这种方法对于保障连接安全至关重要，特别是当涉及 HTTPS 时。

CONNECT 本身并不处理任何实际数据。它的作用是建立一个安全通信路径，允许加密信息通过代理而不被修改或检查。

CONNECT 的工作原理

1. 发送 CONNECT 请求：客户端（如网络浏览器）向代理服务器发送 CONNECT 请求。该请求包含目标服务器的主机名和端口，通常是标准的 HTTPS 端口 (443)。例如，当访问 https://example.com 时，浏览器向代理服务器发送 CONNECT 请求，请求其连接到该域的端口 443。

2. 建立隧道：代理服务器在收到 CONNECT 请求后，建立一条到目标服务器的隧道。该隧道允许加密通信无干扰地通过。代理仅在客户端和目标之间转发流量，充当中继的角色。

3. 加密通信：隧道建立后，客户端和目标服务器可以使用安全加密协议（如 TLS，用于 HTTPS）直接通信。由于数据在客户端和服务器之间是加密的，代理无法解密或修改它。

4. 安全数据传输：通过 CONNECT 方法，敏感数据（如登录凭证、个人信息或金融交易）可以在客户端和服务器之间安全传输，即使是通过代理。加密隧道确保数据保持机密和完整。

CONNECT 请求和响应示例

• CONNECT 请求：

    CONNECT example.com:443 HTTP/1.1
    Host: example.com
  

• 代理响应（若隧道成功建立）：

    HTTP/1.1 200 Connection Established
  

CONNECT 隧道

在此环境中，隧道一词指的是通过代理在客户端和目标服务器之间创建直接、安全的链接。代理作为中间人存在，但不会干涉或访问通过隧道传输的加密数据。

隧道过程的步骤：

• 发送 CONNECT 请求：客户端向代理发送 CONNECT 请求，指定目标服务器和端口（例如，HTTPS 的 443 端口）。

• 代理设置隧道：代理服务器在客户端和目标服务器之间建立安全隧道，在两个端点之间转发流量。

• 开始加密通信：客户端和目标服务器通过加密隧道直接通信，使用 HTTPS 或其他加密协议。代理转发加密流量但无法访问或修改。

CONNECT 方法的典型使用案例

1. 通过代理的 HTTPS：CONNECT 方法最常见的用途之一是启用通过代理的 HTTPS 流量。在许多公司或网络环境中，互联网流量必须通过代理服务器。对于使用 HTTPS 的安全网站，CONNECT 方法允许代理服务器建立隧道，在不检查数据的情况下将加密流量从客户端转发到目标服务器。

   • 示例：当您从公司网络访问一个安全的银行网站时，您的浏览器可能需要通过公司代理。CONNECT 方法用于在您的浏览器和银行网站之间建立加密隧道，确保敏感数据（如登录凭证）安全地通过代理。

2. VPN 和安全通道：**VPN（虚拟专用网络）**服务也依赖类似的隧道技术来安全地加密和路由互联网流量。一些 VPN 服务使用 CONNECT 创建安全隧道，确保用户与互联网之间传输的数据加密且不被窃听。

3. 访问被封锁的内容：在某些网站被封锁的环境中（例如，学校或办公室），CONNECT 有时可以用于通过代理建立隧道来绕过限制。虽然这种做法可能违反网络政策，但它说明了 CONNECT 如何用于建立安全、不受监控的访问。

4. 自定义代理：开发人员可能会设置自定义代理来为应用程序路由流量以提高性能或安全性。在这种情况下，CONNECT 允许 HTTPS 或其他安全流量通过代理传输，同时保持隐私和安全，因为代理服务器无法访问隧道内的加密数据。

虽然 CONNECT 对于安全通信是必不可少的，但它也带来了一些安全挑战：

• 绕过内容过滤器：由于 CONNECT 创建了代理无法检查的加密隧道，它可以被用来绕过内容过滤系统。这使用户能够访问受限的网站或服务，可能违反组织政策。

• 隧道传输恶意流量：恶意行为者可以利用 CONNECT 通过代理隧道传输有害或未经授权的流量。由于流量是加密的，防火墙和安全系统可能无法检测到恶意活动。

• 缓解措施：许多组织通过密切监控和限制 CONNECT 方法的使用来解决这些风险。一些代理执行 SSL 截取 来解密和检查 HTTPS 流量，尽管这会引发隐私问题并可能影响用户安全。

结论

HTTP 方法对于实现 web 应用程序和服务器之间的通信至关重要。从 GET 到 CONNECT，每个方法都为特定任务设计，如发送数据、检索信息、更新资源或建立安全连接。为任务选择正确的方法可以提高应用程序的效率和安全性。

GET 适合检索数据，POST 和 PUT 帮助创建和更新，PATCH 处理部分更新，而 DELETE 用于移除资源。HEAD 检查响应头而不检索内容，OPTIONS 显示支持的方法，TRACE 和 CONNECT 有助于调试和安全通信。

使用适当的 HTTP 方法确保您的应用程序高效、安全地运行，为用户提供流畅的体验。

如果您有任何问题或建议，请随时在 LinkedIn 上联系。如果您喜欢这篇内容，请考虑 buy me a coffee 来支持我创作更多对开发者友好的内容。

上网时收到任何错误代码都可能是一种令人沮丧的经历。虽然我们已经习惯了 404 Not Found 的页面，甚至在我们访问不到的时候经常有可爱的占位符页面来令人开心，但更令人费解的错误之一是 403: Forbidden response。

它是什么意思？

简单地说：服务器已经确定你不能访问你所请求的东西。

根据 RFC 7231，

403（禁止）状态代码表明服务器理解该请求，但拒绝授权......如果请求中提供了认证凭证，服务器认为它们不足以授予访问权。

403 响应属于 HTTP 响应的 4xx 范围：客户端错误。这意味着你或你的浏览器做错了什么。

如果你遇到这种情况，通常意味着你已经在服务器上验证了自己的身份，也就是说，你已经登录了，但你所请求的资源需要有更高权限的人。

最常见的情况是，你可能是以标准用户身份登录的，但你正试图访问一个管理员页面。

你如何解决这个问题？

作为一个不能访问服务器的用户，你实际上只有几个选择：

用一个更合适的账户认证

同样，根据 RFC 7231 的规定：

如果在请求中提供了认证凭证，服务器认为它们不足以授予访问权，客户端不应该自动用相同的凭证重复请求，客户端可以用新的或不同的凭证重复请求。

这是唯一能让你立即纠正问题的方法。

如果你在一个网站上有多个账户，你试图做一些你通常可以做的事情，但这次被禁止做，这是你应该尝试的选项。用你的其他账户登录。

你可能会发现，这个选项也需要清除你的缓存或 cookies，以防以另一个用户身份登录时不能充分刷新之前的认证令牌。但这通常是不必要的。

作为一个无奈之举，你也可以尝试禁用可能干扰你使用该网站的浏览器扩展。然而，这是不可能的，因为 403 意味着你已被认证，但没有被授权。

通知网站所有者返回的是 403

如果你完全预计你应该能够访问有关资源，但你仍然看到这个错误，明智的做法是让网站背后的团队知道——这可能是他们的一个错误。

再来看看 RFC 7231 的内容：

然而，一个请求可能因为与证书无关的原因而被禁止。

无意中发生这种情况的一个常见原因是，服务器对特定的 IP 地址或地理区域使用了允许或拒绝名单。

他们可能有很好的理由阻止你在他们严格定义的参数之外的访问，但也可能只是一个疏忽。

放弃

也许你只是不应该能够访问该资源。这种情况时有发生。互联网很大，有一些区域不允许你个人访问，这是合理的。

你可以在思考为什么你的原始请求被禁止时转而访问 http.cat。

我们每天都和HTTP和HTTPS打交道，但是很多人都不知道这两者之间的区别是什么。

大多数计算机用户看到浏览器告知他们这个应用不安全，很有可能有黑客想要获取他们重要的信息的时候，用户可能跑得比博尔特还要快。

但这个安全风险是可以避免的，这就是为什么HTTPS引入并取代HTTP。今天我们就来讨论这个话题。 :)

我们将讨论：

1. 什么是HTTP
2. HTTP如何工作
3. HTTP的功能
4. 如何知道一个网站不安全
5. 所有的HTTP网站都不安全吗
6. 什么是HTTPS
7. HTTPS如何工作
8. HTTPS的功能
9. 加密的工作原理
10. 如何知道一个网站是安全的
11. SSL证书是什么
12. SSL是如何工作的
13. 如何给我的网站申请SSL
14. 在哪里申请SSL证书
15. 可以免费获取SSL证书吗
16. HTTPS和HTTP的主要区别
17. 总结

什么是HTTP

超文本传输协议（HTTP）是浏览器和你想要访问的网站（web服务器）之间的一种沟通方法。

协议允许你通过浏览器从服务器获取你想要的信息。

通过类比来了解HTTP和HTTPS是一个很好的办法。我们都知道浏览器和服务器是通过HTTP来进行通信的。HTTP通常是纯文本。就好比世界上大多数人都说英语，如果一个黑客知道怎么说英语，并且黑进了你的电脑，这样他就可以很轻易地获取你的密码。

但是在肯尼亚，我们的母语是图尔卡纳语。如果你不了解这门语言，并且在肯尼亚发现两个图尔卡纳人在对话，你就会听不懂他们在说什么。

这就是HTTPS的精华所在。它做了加密处理，理论上黑客不知道浏览器和服务器之间发生了什么通信。

如果我登陆了http://www.google.com，我会看到谷歌的默认页面。

客户端（大多数情况下是浏览器）发送一个信息，在计算机术语中叫做请求（request）。然后服务器应答，通常被称为响应（response）。

HTTP可以有效地发送HTML文档、图片和视频到web浏览器，方便用户观看。HTTP同样也使用HTML格式将数据传输到服务器。

HTTP如何运作

HTTP通过纯文本传输数据。举个例子，如果你在访问你的银行网页，这个网页使用的是HTTP，那么黑客就可以访问这个页面，并且读取任何你发送的信息。

此时HTTPS就派上用场了。许多公司都应用了HTTPS，确保用户安全地发送信息。我们会在后文章讨论。

HTTP的特征

• 纯文本。在HTTP创建之初，开发者们只想解决一个问题：仅服务于文本文件。现在，HTTP已经被运用于文本以外更多地方。

• 七层协议。HTTP是网络通信OSI模型的第七层协议。第七层是应用层，也是OSI模型的最外层。 其他的层级包括物理层、数据链路层、网络层、传输层、会话层和表示层。想要了解更多OSI模型的信息，可以参考这篇文章，以及freeCodeCamp的YouTube频道里由Brain Ferrill讲解的网络工作的视频。视频中包含除了OSI以外更多精彩内容。Computer Networking Course - Network Engineering [CompTIA Network+ Exam Prep]

• 不安全。当你通过纯文本发送HTTP请求的时候，你同样也收到纯文本响应。也就是说任何可以访问这些请求和响应的人都可以读取这些信息。
  

• 轻量。HTTP的优势在于轻量。因为没有像HTTPS一样，通过加密来保护数据，所以HTTP传输速度非常快。

• HTTP通常在端口80监听。

如何知道一个网站不安全

当网站不安全的时候，Chrome通常会发出一个警告：Your connection is not private（你的连接不是私人的）。

在Chrome的URL输入框内通常会显示红色的Not Secure（不安全）。

所有的HTTP网站都不安全吗

假设你正在浏览一个meme网站，一边滚动图片一边哈哈大笑。如果网站使用的是HTTP协议，这没什么大不了。

这时你觉得有些无聊了，打算登陆你的银行的网站，网站没有使用HTTPS协议，此时你就向黑客双手奉上了你的账户信息。

所以安全的底线是你浏览的信息是否无关紧要。如果不重要，HTTP是安全的，但是如果是需要保密的信息，HTTP就不够用。

什么是HTTPS

超文本传输安全协议，即HTTPS是浏览器和你登陆的网站（服务器）之间安全的通信。

HTTPS如何运作

HTTPS通过加密数据这样的安全协议来确保通信的安全。

对于大多数网站来说，拥有HTTPS的方式是获取一个SSL（Secure Sockets Layer安全套接层）或者TLS（Transport Layer Security传输层安全协议）证书。

现在，SSL已经兼容TLS，所以你没有必要获取一个TLS证书。

HTTPS的特证

• 加密数据。通过TLS/SSL协议来加密数据。
• 是第四层（传输层）协议。
• 公钥和私钥的密钥交换发生在HTTPS中以加密和解密数据。
• 不如HTTP轻量。当HTTPS发生加密和解密的时候，就变得笨重。
• HTTPS在端口443监听。

加密的工作原理

假设我输入“I am a dev（我是一个开发者）。”当我点击发送的时候，这段文字会被加密，然后在服务器端被解密。

服务器端也是同样的道理。从服务器发送的响应，会先被加密处理然后再到客户端被解密。

如何知道一个网站是安全的

检查一个网站是否是安全的，你通常可以查看URL信息栏是否有一把锁。如果有一把锁，则服务器和客户端之间的通信就是安全的。

当你点击这个锁的图标，就会看到安全连接的更多信息。

SSL证书是什么

SSL证书是一个小文件，告诉你的浏览器，比方说，freecodecamp.org是它所声称的网站，并且是可靠的。

证书的认证即是向客户（用户）确认他们所连接的服务器是管理该域（domain）的服务器。认证是为了使用户免受如域名欺骗这样的安全问题的影响。

证书包含一个公钥，并告诉你正在尝试连接的网站的所有者是谁。如果网站没有SSL证书，则无法使用TLS加密。

如果你是网站所有者，你可以创建自己的SSL证书（也称为自签名证书）。但这种方法的问题在于Chrome等浏览器不信任这些证书。它们倾向于信任由证书颁发机构颁发的证书。

SSL是如何运作的

SSL加密有两种类型，非对称和对称。SSL加密结合了这两种加密方式。下文会做详细介绍：

什么是非对称加密

在非对称加密中，你拥有两把密钥：

1. 公钥
2. 私钥

客户端/用户/浏览器在通信的时候给服务器提供公钥，然后通过公钥进行加密，服务器通过私钥进行解密。

私钥只能在该特定服务器上找到，其他任何人都没有。这就是为什么非对称加密更强大且更难破解，因为它有两个不同的密钥，私钥和公钥。这两个密钥协同工作以确保数据更安全。

这也是为什么这种加密的长度是1024/2048位。

什么是对称加密

对称加密就简单很多。你只有一把密钥。客户端使用一个密钥进行加密，服务器使用相同的密钥解密数据。

对称加密更轻量。长度为128/256位。但与非对称相比，它更容易被入侵，这并不意味着它没有用。当我们使用SSL时，我们将非对称和对称结合起来，能够使通信更安全、更私密。

非对称 + 对称加密的工作原理

非对称和对称的组合形成双层防护墙

在第一步中，服务器向浏览器发送非对称的公钥。如我们所知，非对成密匙包含一个公钥和一个私钥，因此浏览器收到公钥。

之后，浏览器生成一个会话密钥。

对称加密中客户端和服务器都只使用一个密钥。所以接下来，浏览器将生成一个本地会话密钥，是一个对称加密会话密钥。然后它将使用第一步中的非对称公钥对其进行加密。本地生成的会话密钥与公钥组合，发送到服务器。

然后，服务器将使用私钥解密它收到的加密会话密钥。在这个特定步骤中，服务器将使用非对称私钥来解密它收到的会话密钥。

现在，一旦解密发生，服务器和浏览器将使用会话密钥进行通信。会话密钥将仅用于这次特定会话。

假设你关闭了浏览器，并在第二天登录 —— 一切重新开始，会话密钥会再次被创建。

如何给我的网站申请SSL

如果你是网站所有者，你可以从证书颁发机构获取SSL证书。

然后在托管网站的Web服务器上安装证书。大多数情况下，托管网站的托管公司会为你处理此过程。

在哪里申请SSL证书

有些组织颁发安全证书，这些组织称为证书颁发机构。其中一些证书颁发机构包括：DigiCert、Comodo等。

许多开发人员从这些组织获得证书。由于这些组织办法的证书是使用最广泛，浏览器通常信任来自这些组织的证书。

可以免费获取SSL证书吗

Cloudflare免费提供SSL证书。它是最早采取这一行动的互联网安全公司之一。

如果你想申请一个，可以点击这里。

HTTPS的用途

HTTPS在安全性方面起到了很大的作用。没有它，传递敏感信息将成为一个巨大的挑战，尤其是当你的企业需要一种安全的通信方式时。

接受在线支付的网站（如电子商务网站）通常需要HTTPS。这是为了避免信用卡详细信息和登录信息等被盗 (引用: Tony Messer)。

HTTPS和HTTP的主要区别

• HTTPS中启用了加密层，而HTTP中没有加密层。
• 数据在HTTPS中受到保护，而在HTTP中则不受保护。
• 当使用HTTPS时，网站在Google中的排名会提高，而使用HTTP时，不会获得任何排名提升。
• 使用HTTPS可以防止网络钓鱼，而使用HTTP没有保护。
• 使用HTTPS符合支付行业规定，但是HTTP不合规。
• 在最初几秒钟内加载HTTPS可能比加载HTTP慢。
• 获得SSL证书可能需要花钱，而HTTP没有认证成本。
• 在chrome上使用HTTPS网站更方便，使用HTTP网站会经常收到不安全提示。

总结

HTTP和HTTPS在开发者的日常生活中扮演了重要的角色，浏览器和服务器之间的通信是我们工作的动力。

尽可能地保护用户的数据，以防止他们的信息被盗，将获得用户的信任并提供更好的用户体验。

下篇文章见。

在本文中，我们将讨论 get、put 和 post HTTP 方法，介绍每种 HTTP 方法的用途以及使用场景。

为了深入了解 HTTP 方法的工作原理，本文还将介绍 HTTP 有关上下文和背景信息。

这篇文章讲要介绍的主题：

• HTTP 协议
• 客户端-服务器架构
• APIs

读完本文，将对每个请求方法的定位有一个很好的了解。还将具备发起请求和使用 Web API 的经验。

什么是 HTTP？

HTTP 是一种协议，或一组明确的规则，用于访问网络上的资源。资源可以是任何东西，从 HTML 文件到数据库中的数据、照片、文本等等。

通过 HTTP 协议向这些 API 发出请求，然后返回相应的资源。API代表应用程序编程接口。它是开发人员请求资源的机制。

客户端-服务器架构

学习 HTTP 方法前，理解客户端/服务器架构的概念很重要。该架构描述了 Web 应用程序的工作方式，并定义了通信的规则。

客户端是用户实际与之交互的应用程序，它展示所需的内容。服务器是将内容或资源发送到客户端的应用程序。服务器在某处持续运行等待客户端的请求。

这种分离的主要原因是为了保护敏感信息。如果整个应用程序都被下载到浏览器中，任何访问网页的人都可以访问所有数据。

这种架构有助于保护 API 密钥、个人数据等。现在，Next.js 和 Netlify 等流行工具允许开发人员在与其客户端程序中运行服务器代码， 无需部署到专用的服务器上。

客户端-服务器通信

客户端和服务器根据需要每次单独发送消息进行通信，而不是持续的流通信。

这些通信几乎总是由客户端以请求的形式发起。这些请求由服务器应用程序完成，返回包含请求的资源的响应。

为什么我们需要服务器-客户端架构？

假设正在构建一个网络天气应用。用户要与之交互的是客户端程序——它有按钮、搜索栏，并显示城市名称、当前温度、AQI 等数据。

天气应用不会将每个城市及其天气信息直接硬编码到程序中。这会使应用程序变得臃肿而缓慢，检索数据添加到数据库需要花费很长时间，而且每天的更新的也很让人头疼。

相反，该应用程序可以使用 Weather Web API 按城市访问天气数据。应用程序会收集用户的位置，然后向服务器发出请求，说：“嘿，把这个城市的天气信息发给我。”

根据要实现的目标，将使用不同的请求方法。服务器返回一个包含天气信息等内容的响应，具体取决于 API 的设计。它还可能会返回时间戳、该城市所在的区域等信息。

客户端与运行在某处的服务器进行通信，服务器的工作就是不断地到监听是否有到该地址的请求。当它接收到请求时，它会基于传入的参数从数据库或者另一个 API 或者本地文件查询返回符合要求的响应。

HTTP 请求剖析

HTTP 请求必须具有以下内容：

• HTTP 方法（如 GET）
• 主机 URL（如https://api.spotify.com/）
• 端点路径（如 v1/artists/{id}/related-artists）

请求还可选包含：

• Body 请求体
• Headers
• 查询字符串
• HTTP 版本号

HTTP 响应剖析

响应必须具有以下内容：

• 协议版本（如HTTP/1.1）
• 状态码（如 200）
• 状态文本（OK）
• Headers

响应还可选具有：

• Body 响应体

HTTP 方法解释

Post Malone 意味着 Get、Put、Patch 和 Delete Malone 的存在。

— Paul Ford (@ftrain) November 15, 2019

现在我们知道了什么是 HTTP 以及为什么需要它，让我们来聊聊这些不同的 HTTP 方法。

在上面的天气应用程序示例中，我们想要检索某城市的天气信息。但是如果我们想提交一个城市的天气信息该如何请求呢？

在现实生活中，可能无权更改其他人的数据，但假设我们是社区运行的天气应用程序的贡献者。除了从 API 获取天气信息外，该城市的成员还可以更新此信息以显示更准确的数据。

或者，如果我们想完全添加一个由于某种原因在我们的城市数据库中不存在的新城市怎么办？ 这些是不同的功能——检索数据、更新数据、创建新数据——所有这些都有对应的 HTTP 方法。

HTTP POST 请求

POST 用来创建一个新资源。POST 请求需要一个请求体，可以在其中定义要创建的实体数据。

POST 请求成功返回的状态码是 200。在天气应用中，可以使用 POST 方法来添加新城市。

HTTP GET 请求

GET 用来读取或检索资源。 GET 成功后会返回包含所请求信息的响应。

在天气应用中，可以使用 GET 来检索某城市当前的天气。

HTTP PUT 请求

PUT 用来修改资源。PUT 用请求体 payload 中的数据替换整个资源。如果没有与请求体唯一标识相匹配的资源，它将创建一个新资源。

在天气应用中，可以使用 PUT 来更新指定城市的所有天气数据。

HTTP PATCH 请求

PATCH 用来修改资源的部分字段。使用 PATCH，只需要传入想要更新的字段即可。

在天气应用中，可以使用 PATCH 来更新指定城市指定日期的降雨量。

HTTP 删除请求

DELETE 可以用来删除资源。在天气应用中，可以使用 DELETE 删除出于某种原因不再想跟踪的城市。

HTTP Methods 常见问题解答

PUT 和 POST 有什么区别？

PUT 请求是幂等的，这意味着执行相同的 PUT 请求将始终产生相同的结果。

另一方面，POST 会产生不同的结果。如果多次执行 POST 请求，将多次创建新资源，尽管传入的是相同的数据。

使用餐厅类比，多次 POST 会创建多个独立的订单，而多次 PUT 请求将更新现有的订单。

PUT 和 PATCH 有什么区别？

主要区别在于，如果 PUT 找不到指定的资源，它将创建一个新资源。而使用 PUT 时，需要传入改数据的全部资源，即使只想修改一个字段。

使用 PATCH，可以只传入要更新字段更新资源。

如果我只想更新我的部分资源怎么办？我还能使用 PUT 吗？

如果只想更新部分资源，则在发出 PUT 请求时仍需要发送整个资源的数据。这里更适合的选项是 PATCH。

为什么请求和响应的 body 是可选的？

body 是可选的，因为对于某些请求，例如使用 GET 方法检索资源，请求正文中无需指定任何内容。可以从指定端点检索所有数据。

类似地，当状态码足够或正文中没有要返回的内容时，某些响应的主体是可选的，如 DELETE 操作。

HTTP 请求示例

现在已经介绍了什么是 HTTP 请求，以及它们的使用场景，让我们发起一些请求！这里将使用 GitHub Gist API。

“Gist 是一种与他人共享代码段的简单方法。所有 Gist 都是 Git 仓库，因此可以使用 Git 的版本控制，fork 等功能。” （来源：GitHub）

为此，需要一个 GitHub 帐户。如果还没有，这是一个很好的时机来创建一个以在将来保存代码。

GitHub 上的每个用户都可以创建 gist、检索他们的 gist、检索所有公共 gist、删除 gist 和更新 gist，等等。为了简单起见，我们将使用 Hoppscotch，这是一个可以方便地发起 HTTP 请求的一个可视化平台。

快速上手 Hoppscotch：

• 有一个下拉菜单，可以在其中选择要用来创建请求的 method。
• 有一个文本框，可以在其中粘贴要访问的 API 端点的 URL。

• 有一个 Headers 部分，我们将按照 GitHub 文档的说明在其中传递请求头。

• 有一个 body 区域，可以按照 GitHub 文档的指示将相应的请求实体写入 body。

• 如果请求成功，右栏会显示通知。如果它是绿色的，表示成功发起了请求，如果它是红色的，代表有错误。

如何发出 GET 请求

要创建 GET 请求以检索所有特定用户的 gists，可以使用以下方法和端点：GET /users/{username}/gists。按照文档可以通过 endpoint 传入指定的参数来发起请求。

可以看到在路径中需要传入一个带有目标用户用户名的字符串。还需要传入一个名为 accept 的 headers 并将其设置为 application/vnd.github.v3+json。

API 的 URL 为：

https://api.github.com

此特定操作的端点路径为：

/users/{username}/gists

要发起此请求：

1. 在 Hoppscotch 的输入字段中粘贴完整的 URL + 路径。请务必将 “username” 替换为实际用户名。如果还没有创建过 Gists 的 GitHub 账号，可以先使用我的：camiinthisthang。
2. 选择GET请求方法
3. 在 Headers 选项卡中，将 accept 设置为 header 并将值设置为 application/vnd.github.v3+json

4. 点击发送！

在底部，会看到格式为 JSON 的响应。为了便于阅读，复制响应并将其粘贴到 在线 JSON 格式化程序。

在格式化程序中，可以知道响应是一个对象数组。每个对象代表一个 gist，向我们展示 URL、ID 等信息。

如何发出 POST 请求

现在来使用 POST 方法创建一个资源。在这种情况下，新资源将是一个新的 gist。

首先，需要创建一个个人 access token。为此，转到设置页面并点击生成令牌。

命名 token 并选择 scope “Create Gists”：

然后单击页面底部的绿色 Generate token 按钮。

复制 access 代码并将其粘贴到合适的位置。

现在准备好发起的请求了！根据文档应该在 body 中传递一个 headers 和一个 files 对象。可选传入一些其他参数，包括一个布尔值，它代表这个 gist 是公共的还是私有的。

API 的 URL 如下：

https://api.github.com

此操作的端点路径如下：

/gists

要发起此请求：

1. 将完整的 URL + 路径粘贴到 Hoppscotch 的输入字段中。

2. 选择POST请求方法

3. 在 Headers 选项卡中，将 accept 设置为 header 并将值设置为 application/vnd.github.v3+json

4. 在 Body 选项卡中，将内容类型设置为 application/json。然后从一个对象{}开始。

   在这个对象内部，将 public boolean 设置为 true。然后将定义属性 files，其值是另一个对象，其键名是新 gist 名称。值应该是另一个其键为 content 的对象。这里的值应该是想要实际添加到要点中的任何值。

   可以复制/粘贴以下代码：

{
  "public": true, 
  "files": {
    "postgist.txt": {
      "content": "Adding a GIST via the API!!"
    }
  }
}

5. 在 Authorization 选项卡中，将授权类型设置为 Basic Auth。输入 GitHub 用户名并传入在密码字段中创建的个人访问令牌。

在执行这个之后，会得到一个很长的响应。检查 gist 是否已创建的一种简单方法是访问 GitHub 中的 Gist。

可以看到成功添加了一个 Gist！

如何创建 PATCH 请求

来更新刚刚创建的 Gist 的标题和描述。请记住：PATCH 允许更新资源的一部分，而不是整个资源。我们没有传入的任何内容都将保持不变。

在创建 Gist 时实际上并没有提供描述，因此我们可以使用 patch 创建一个。

API 的 URL：

https://api.github.com

此特定操作的端点路径如下：

/gists/{gist_id}

要创建此请求：

1. 在 Hoppscotch 的输入字段中粘贴完整的 URL + 路径。获取要更新的 gist 的 Gist ID。可以通过转到 GitHub 中的 Gist 并复制 URL 末尾的字母数字字符串来找到 ID。

2. 选择 PATCH 请求方法。

3. 在 Headers 选项卡中，将 accept 设置为 header 并将值设置为 application/vnd.github.v3+json。

4. 在 Authorization 选项卡中，将授权类型设置为 Basic Auth。输入 GitHub 用户名并传递我们在密码字段中创建的个人 access token。

5. 在 Body 选项卡中，传入更新后的描述和标题。代码如下：

{
  "description": "Adding a description via the API", 
  "files": {
    "postgist.txt": {
      "content": "Adding a GIST via the API!! -- adding this line at the end to make the content slightly longer"
    }
  }
}

刷新 Gist，会看到标题和描述已经更新！

如何发起 DELETE 请求

要删除创建的 Gist。应该传入 header 和 Gist ID。

API 的 URL 如下：

https://api.github.com

此特定操作的端点路径如下：

/gists/{gist_id}

要创建此请求：

1. 在 Hoppscotch 的输入字段中粘贴完整的 URL + 路径。获取要更新的 gist 的 Gist ID 。可以通过转到 GitHub 中的 Gist 并复制 URL 末尾的字母数字字符串来找到 ID。

2. 选择 DELETE 请求方法

3. 在 Headers 选项卡中，将 accept 设置为 header 并将值设置为 application/vnd.github.v3+json。

导航到 Gists，会看到已经成功地删除了该资源。

如何在程序中发起请求

使用 Hoppscotch 是因为它可以方便的发起请求，而无需启动程序或下载任何内容。

如果想在 JavaScript/React 应用程序中发出请求，可以使用 Javascript fetch 或 Axios。

有关如何发起使用 HTTP 请求方法和 API 的简单应用程序的步骤演示，可以查看我在 youtube 上的视频，我们在其中创建了一个 Web 应用程序，该应用程序通过 API 显示有关所有国家/地区的信息 .

你做到了！

如果你正在阅读本文，请继续给自己点赞，因为你已经了解了 Web API、HTTP 协议、客户端-服务器架构——并且还发起了第一个请求。

如果你喜欢我的风格，可以在 YouTube、[Tik Tok](https:// www.tiktok.com/@camiinthisthang?)、Twitter 和 Hashnode 找到我。还可以通过 我的个人网站 找到代码片段和联系我的方式。

在这篇文章中，我将尽量用通俗易懂的方式来向读者讲述 HTTP 的知识。我建议大家在学习 HTTP 知识的时候，利用 Chrome 开发者工具来做实践，这可以帮助我们理解得更深刻。

HTTP 概述

HTTP 超文本传输​​协议是位于 TCP/IP 体系结构中的应用层协议，它是万维网数据通信的基础。

当我们访问一个网站时，需要通过统一资源定位符（uniform resource locator，URL）来定位服务器并获取资源。

<协议>://<域名>:<端口>/<路径>

一个 URL 的一般形式通常如上所示（http://test.com/index.html ），现在最常用的协议就是 HTTP，HTTP 的默认端口是 80，通常可以省略。

HTTP/1.1

HTTP/1.1 是目前使用最广泛的版本，一般没有特别标明版本都是指 HTTP/1.1。

HTTP 连接建立过程

我们来看一下在浏览器输入 URL 后获取 HTML 页面的过程。

1. 先通过域名系统（Domain Name System，DNS）查询将域名转换为 IP 地址。即将 test.com 转换为 221.239.100.30 这一过程。
2. 通过三次握手（稍后会讲）建立 TCP 连接。
3. 发起 HTTP 请求。
4. 目标服务器接收到 HTTP 请求并处理。
5. 目标服务器往浏览器发回 HTTP 响应。
6. 浏览器解析并渲染页面。

下图中的 RTT 为往返时延（Round-Trip Time： 往返时延。表示从发送端发送数据开始，到发送端收到来自接收端的确认，总共经历的时延）。

HTTP 连接拆除过程

所有 HTTP 客户端（浏览器）、服务器都可在任意时刻关闭 TCP 连接。通常会在一条报文结束时关闭连接，但出错的时候，也可能在首部行的中间或其他任意位置关闭连接。

TCP 三次握手和四次挥手

由于 HTTP 是基于 TCP 的，所以打算在这补充一下 TCP 连接建立和拆除的过程。

首先，我们需要了解一些 TCP 报文段的字段和标志位：

1. 32 比特的序号字段和确认号字段，TCP 字节流每一个字节都按顺序编号。确认号是接收方期望从对方收到的下一字节的序号。
2. ACK 标志位，用于指示确认字段中的值是有效的 ACK=1 有效，ACK=0 无效。
3. SYN 标志位，用于连接建立，SYN 为 1 时，表明这是一个请求建立连接报文。
4. FIN 标志位，用于连接拆除，FIN 为 1 时，表明发送方数据已发送完毕，并要求释放连接。
   

TCP 三次握手建立连接

TCP 标准规定，ACK 报文段可以携带数据，但不携带数据就不用消耗序号。

1. 客户端发送一个不包含应用层数据的 TCP 报文段，首部的 SYN 置为 1，随机选择一个初始序号（一般为 0）放在 TCP 报文段的序号字段中。（SYN 为 1 的时候，不能携带数据，但要消耗掉一个序号）
2. TCP 报文段到达服务器主机后，服务器提取报文段，并为该 TCP 连接分配缓存和变量。然后向客户端发送允许连接的 ACK 报文段（不包含应用层数据）。这个报文段的首部包含 4 个信息：ACK 置 为 1，SYN 置为 1；确认号字段置为客户端的序号 + 1；随机选择自己的初始序号（一般为 0）。
3. 收到服务器的 TCP 响应报文段后，客户端也要为该 TCP 连接分配缓存和变量，并向服务器发送一个 ACK 报文段。这个报文段将服务器端的序号 + 1 放置在确认号字段中，用来对服务器允许连接的报文段进行响应，因为连接已经建立，所以 SYN 置为 0。最后一个阶段，报文段可以携带客户到服务器的数据。并且以后的每一个报文段，SYN 都置为 0。

下图是一个具体的示例：

TCP 四次挥手拆除连接

FIN 报文段即使不携带数据，也要消耗序号。

1. 客户端发送一个 FIN 置为 1 的报文段。
2. 服务器回送一个确认报文段。
3. 服务器发送 FIN 置为 1 的报文段。
4. 客户端回送一个确认报文段。

TCP 为什么是四次挥手，而不是三次？

1. 当 A 给 B 发送 FIN 报文时，代表 A 不再发送报文，但仍可以接收报文。
2. B 可能还有数据需要发送，因此先发送 ACK 报文，告知 A “我知道你想断开连接的请求了”。这样 A 便不会因为没有收到应答而继续发送断开连接的请求（即 FIN 报文）。
3. B 在处理完数据后，就向 A 发送一个 FIN 报文，然后进入 LAST_ACK 阶段（超时等待）。
4. A 向 B 发送 ACK 报文，双方都断开连接。

参考资料：

• 知乎网友-魔方的回答

HTTP 报文格式

HTTP 报文由请求行、首部、实体主体组成，它们之间由 CRLF（回车换行符） 分隔开。

注意：实体包括首部(也称为实体首部)和实体主体，sp 即是空格 space。

请求行和首部是由 ASCII 文本组成的，实体主体是可选的，可以为空也可以是任意二进制数据。

请求报文和响应报文的格式基本相同。

请求报文格式：

<method> <request-URL> <version>
<headers>
<entity-body>

响应报文格式：

<version> <status> <reason-phrase>
<headers>
<entity-body>

一个请求或响应报文由以下字段组成：

1. 请求方法，客户端希望服务器对资源执行的动作。
2. 请求 URL，命名了所请求的资源。
3. 协议版本，报文所使用的 HTTP 版本。
4. 状态码，这三位数字描述了请求过程中所发生的情况。
5. 原因短语，数字状态码的可读版本（例如上面的响应示例跟在 200 后面的 OK，一般按规范写最好）。
6. 首部，可以有零或多个首部。
7. 实体的主体部分，可以为空也可以包含任意二进制数据。

一个 HTTP 请求示例：

GET /2.app.js HTTP/1.1
Host: 118.190.217.8:3389
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36
Accept: */*
Referer: http://118.190.217.8:3389/
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9

一个 HTTP 响应示例：

HTTP/1.1 200 OK
X-Powered-By: Express
Accept-Ranges: bytes
Cache-Control: public, max-age=0
Last-Modified: Sat, 07 Mar 2020 03:52:30 GMT
ETag: W/"253e-170b31f7de7"
Content-Type: application/javascript; charset=UTF-8
Vary: Accept-Encoding
Content-Encoding: gzip
Date: Fri, 15 May 2020 05:38:05 GMT
Connection: keep-alive
Transfer-Encoding: chunked

方法

GET 和 HEAD

其中 GET 和 HEAD 被称为安全方法，因为它们是幂等的（如果一个请求不管执行多少次，其结果都是一样的，这个请求就是幂等的），类似于 POST 就不是幂等的。

HEAD 方法和 GET 方法很类似，但服务器在响应中只返回首部。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。使用 HEAD，可以：

1. 在不获取资源的情况下了解资源的情况。
2. 通过查看响应状态码，看看某个对象是否存在。
3. 通过查看首部，了解测试资源是否被修改了。

服务器开发者必须确保返回的首部与 GET 请求所返回的首部完全相同。遵循 HTTP/1.1 规范，就必须实现 HEAD 方法。

PUT

与 GET 方法从服务器读取文档相反，PUT 方法会向服务器写入文档。PUT 方法的语义就是让服务器用请求的主体部分来创建一个由所请求的 URL 命名的新文档。 如果那个文档已存在，就覆盖它。

POST

POST 方法通常用来向服务器发送表单数据。

TRACE

客户端发起一个请求时，这个请求可能要穿过路由器、防火墙、代理、网关等。每个中间节点都可能会修改原始的 HTTP 请求，TRACE 方法允许客户端在最终发起请求时，看看它变成了什么样子。

TRACE 请求会在目的服务器端发起一个“环回”诊断。行程最后一站的服务器会弹回一条 TRACE 响应，并在响应主体中携带它收到的原始请求报文。 这样客户端就可以查看在所有中间 HTTP 应用程序组成的请求/响应链上，原始报文是否被毁坏或修改过。

TRACE 方法主要用于诊断，用于验证请求是否如愿穿过了请求/响应链。它也是一种工具，用来查看代理和其他应用程序对用户请求所产生的效果。 TRACE 请求中不能带有实体的主体部分。TRACE 响应的实体主体部分包含了响应服务器收到的请求的精确副本。

OPTIONS

OPTIONS 方法请求 Web 服务器告知其支持的各种功能。

DELETE

DELETE 方法就是让服务器删除请求 URL 所指定的资源。

状态码

300~399 重定向状态码

重定向状态码要么告诉客户端使用替代位置来访问他们感兴趣的资源，要么提供一个替代的响应而不是资源的内容。 如果资源已被移动，可以发送一个重定向状态码和一个可选的 Location 首部来告知客户端资源已被移走，以及现在在哪里可以找到它。这样，浏览器可以在不打扰使用者的情况下，透明地转入新的位置。

400~499 客户端错误状态码

有时客户端会发送一些服务器无法处理的东西，例如格式错误的请求报文、一个不存在的 URL。

500~599 服务器错误状态码

有时客户端发送了一条有效请求，服务器自身却出错了。

首部

首部和方法共同配合工作，决定了客户端和服务器能做什么事情。

首部分类：

1. 通用首部，可以出现在请求或响应报文中。
2. 请求首部，提供更多有关请求的信息。
3. 响应首部，提供更多有关响应的信息。
4. 实体首部，描述主体的长度和内容，或者资源自身。
5. 扩展首部，规范中没有定义的新首部。

通用首部

有些首部提供了与报文相关的最基本信息，它们被称为通用首部。以下是一些常见的通用首部：

请求首部

请求首部是只在请求报文中有意义的首部，用于说明请求的详情。以下是一些常见的请求首部：

响应首部

响应首部让服务器为客户端提供了一些额外的信息。

实体首部

实体首部提供了有关实体及其内容的大量信息，从有关对象类型的信息，到能够对资源使用的各种有效的请求方法。

例如内容首部，提供了与实体内容有关的特定信息，说明了其类型、尺寸以及处理它所需的其他有用信息。 另外，通用的缓存首部说明了如何或什么时候进行缓存。实体的缓存首部提供了与被缓存实体有关的信息。

性能优化

1. 减少 HTTP 请求

每发起一个 HTTP 请求，都得经历三次握手建立 TCP 连接，如果连接只用来交换少量数据，这个过程就会严重降低 HTTP 性能。所以我们可以将多个小文件合成一个大文件，从而减少 HTTP 请求次数。

其实由于持久连接（重用 TCP 连接，以消除连接及关闭时延；HTTP/1.1 默认开启持久连接）的存在，每个新请求不一定都需要建立一个新的 TCP 连接。但是，浏览器处理完一个 HTTP 请求才能发起下一个，所以在 TCP 连接数没达到浏览器规定的上限时，还是会建立新的 TCP 连接。从这点来看，减少 HTTP 请求仍然是有必要的。

2. 静态资源使用 CDN

内容分发网络（CDN）是一组分布在多个不同地理位置的 Web 服务器。我们都知道，当服务器离用户越远时，延迟越高。CDN 就是为了解决这一问题，在多个位置部署服务器，让用户离服务器更近，从而缩短请求时间。

3. 善用缓存

为了避免用户每次访问网站都得请求文件，我们可以通过添加 Expires 头来控制这一行为。Expires 设置了一个时间，只要在这个时间之前，浏览器都不会请求文件，而是直接使用缓存。

不过这样会产生一个问题，当文件更新了怎么办？怎么通知浏览器重新请求文件？

可以通过更新页面中引用的资源链接地址，让浏览器主动放弃缓存，加载新资源。

具体做法是把资源地址 URL 的修改与文件内容关联起来，也就是说，只有文件内容变化，才会导致相应 URL 的变更，从而实现文件级别的精确缓存控制。什么东西与文件内容相关呢？我们会很自然的联想到利用数据摘要要算法对文件求摘要信息，摘要信息与文件内容一一对应，就有了一种可以精确到单个文件粒度的缓存控制依据了。

参考资料：

• 张云龙--大公司里怎样开发和部署前端代码？

4. 压缩文件

压缩文件可以减少文件下载时间，让用户体验性更好。

gzip 是目前最流行和最有效的压缩方法。可以通过向 HTTP 请求头中的 Accept-Encoding 头添加 gzip 标识来开启这一功能。当然，服务器也得支持这一功能。

举个例子，我用 Vue 开发的项目构建后生成的 app.js 文件大小为 1.4MB，使用 gzip 压缩后只有 573KB，体积减少了将近 60%。

5. 通过 max-age 和 no-cache 实现文件精确缓存

通用消息头部 Cache-Control 其中有两个选项：

1. max-age: 设置缓存存储的最大周期，超过这个时间缓存被认为过期(单位秒)。在这个时间前，浏览器读取文件不会发出新请求，而是直接使用缓存。
2. no-cache: 指定 no-cache 表示客户端可以缓存资源，每次使用缓存资源前都必须重新验证其有效性。

我们可以将那些长期不变的静态资源设置一个非常长的缓存时间，例如设置成缓存一年。

然后将 index.html 文件设置成 no-cache。这样每次访问网站时，浏览器都会询问 index.html 是否有更新，如果没有，就使用旧的 index.html 文件。如果有更新，就读取新的 index.html 文件。当加载新的 index.html 时，也会去加载里面新的 URL 资源。

例如 index.html 原来引用了 a.js 和 b.js，现在更新了变成 a.js 和 c.js。那就只会加载 c.js 文件。

具体请看 webpack + express 实现文件精确缓存。

HTTPS

HTTPS 是最流行的 HTTP 安全形式，由网景公司首创，所有主要的浏览器和服务器都支持此协议。 使用 HTTPS 时，所有的 HTTP 请求和响应数据在发送之前，都要进行加密。加密可以使用 SSL 或 TLS。

SSL/TLS 协议作用在 HTTP 协议之下，对于上层应用来说，原来的发送/接收数据流程不变，这就很好地兼容了老的 HTTP 协议。由于 SSL/TLS 差别不大，下面统一使用 SSL。

要想了解 HTTPS 为何安全，还得继续了解一下这些概念：加密算法、摘要算法、数字签名和数字证书。

加密算法

对称密钥密码体制

对称密钥密码体制，即加密密钥和解密密钥是使用相同的密码体制。对称密钥加密技术的缺点之一就是发送者和接收者在对话之前，一定要有一个共享的密钥，所以不太安全。

公钥密码体制

公钥密码体制使用不同的加密密钥与解密密钥。公钥密码体制产生的主要原因有两个：一是对称密钥密码体制的密钥分配问题，二是对数字签名的需求。

在公钥密码体制中，加密密钥是公开的，解密密钥是需要保密的，加密算法和解密算法也是公开的。

公钥密码体制的加密和解密有如下特点：

1. 密钥对产生器产生出接收者 B 的一对密钥，即加密密钥 PK 和解密密钥 SK。
2. 发送者 A 用 B 的公钥 PK 作为加密密钥来加密信息，B 接收后用解密密钥 SK 解密。

使用对称密钥时，由于双方使用同样的密钥，因此在通信信道上可以进行一对一的双向保密通信，双方都可以用同一个密钥加密解密。

使用公开密钥时，在通信信道上可以是多对一的单向保密信道。即可以有多人持有 B 的公钥，但只有 B 才能解密。

摘要算法

摘要算法的主要特征是加密过程不需要密钥，并且经过加密的数据无法被解密，目前可以被解密逆向的只有CRC32算法，只有输入相同的明文数据经过相同的消息摘要算法才能得到相同的密文。

数字签名

用加密系统对报文进行签名，以说明是谁编写的报文，同时证明报文未被篡改过，这种技术称为数字签名。

数字签名是附加在报文上的特殊加密校验码。使用数字签名的好处有：

1. 签名可以证明是作者编写了这条报文。只有作者才会有最机密的私有密钥，因此，只有作者才能计算出这些校验和。
2. 签名可以防止报文被篡改，如果有人在报文传输过程中对其进行了修改，校验和就不再匹配了。

数字签名通常是用非对称公开密钥技术产生的。

看上图，任何人都能用 A 的公钥 PK 对密文进行 E 运算后得到 A 发送的明文。可见这种通信并非为了保密，而是为了进行签名和核实签名，即确认此信息是 A 发送的（使用 A 的密钥进行加密的报文，只有使用 A 的公钥才能正确解密）。 但上述过程仅对报文进行了签名，对报文 X 本身却未保密，所以要采用下图的方法，同时实现秘密通信和数字签名。

数字证书

假如你想访问一个网站，怎么确保对方给你的公钥是你想访问的网站的公钥，而不是被中间人篡改过的？

数字证书的出现就是为了解决这个问题，它是由数字证书认证机构颁发的，用来证明公钥拥有者的身份。换句话说，数字证书的作用就相当于人的身份证，身份证证明了张三就是张三，而不是别人。

数字证书一般包含以下内容：

1. 对象的名称（人、服务器、组织等）；
2. 过期时间；
3. 证书发布者（由谁为证书担保）；
4. 来自证书发布者的数字签名；
5. 对象的公钥；
6. 对象和所用签名算法的描述性信息。

任何人都可以创建一个数字证书，但由谁来担保才是重点。

数字证书的数字签名计算过程：

1. 用摘要算法对数字证书的内容计算出摘要；
2. 用数字证书的私钥对摘要进行加密得到数字签名。

当浏览器收到证书时，会对签名颁发机构进行验证，如果颁发机构是个很有权威的公共签名机构，浏览器可能就知道其公开密钥了（浏览器会预装很多签名颁发机构的证书）。如果对签名颁发机构一无所知，浏览器通常会向用户显示一个对话框，看看他是否相信这个签名发布者。

因为数字证书的公钥是公开的，任何人都可以用公钥解密出数字证书的数字签名的摘要，然后再用同样的摘要算法对证书内容进行摘要计算，将得出的摘要和解密后的摘要作对比，如果内容一致则说明这个证书没有被篡改过，可以信任。

这个过程是建立在被大家所认可的证书机构之上得到的公钥，所以这是一种安全的方式。

HTTPS 连接建立过程

HTTPS 连接建立过程和 HTTP 差不多，区别在于 HTTP（默认端口 80） 请求只要在 TCP 连接建立后就可以发起，而 HTTPS（默认端口 443） 在 TCP 连接建立后，还需要经历 SSL 协议握手，成功后才能发起请求。

我知道肯定会有人不满足于简化版的 SSL 握手过程，所以我找了一篇文章SSL/TLS 握手过程详解，这篇文章非常详细的讲解了 SSL 握手的每一步骤。建议有兴趣的同学看一看。

HTTP/2

HTTP/2 是 HTTP/1.x 的扩展，而非替代。所以 HTTP 的语义不变，提供的功能不变，HTTP 方法、状态码、URL 和首部字段等这些核心概念也不变。

之所以要递增一个大版本到 2.0，主要是因为它改变了客户端与服务器之间交换数据的方式。HTTP 2.0 增加了新的二进制分帧数据层，而这一层并不兼容之前的 HTTP 1.x 服务器及客户端——是谓 2.0。

HTTP/2 连接建立过程

现在的主流浏览器 HTTP/2 的实现都是基于 SSL/TLS 的，也就是说使用 HTTP/2 的网站都是 HTTPS 协议的，所以本文只讨论基于 SSL/TLS 的 HTTP/2 连接建立过程。

基于 SSL/TLS 的 HTTP/2 连接建立过程和 HTTPS 差不多。在 SSL/TLS 握手协商过程中，客户端在 ClientHello 消息中设置 ALPN（应用层协议协商）扩展来表明期望使用 HTTP/2 协议，服务器用同样的方式回复。通过这种方式，HTTP/2 在 SSL/TLS 握手协商过程中就建立起来了。

HTTP/1.1 的问题

1. 队头阻塞

在 HTTP 请求应答过程中，如果出现了某种情况，导致响应一直未能完成，那后面所有的请求就会一直阻塞着，这种情况叫队头阻塞。

2. 低效的 TCP 利用

由于 TCP 慢启动机制，导致每个 TCP 连接在一开始的时候传输速率都不高，在处理多个请求后，才会慢慢达到“合适”的速率。对于请求数据量很小的 HTTP 请求来说，这种情况就是种灾难。

3. 臃肿的消息首部

HTTP/1.1 的首部无法压缩，再加上 cookie 的存在，经常会出现首部大小比请求数据大小还大的情况。

4. 受限的优先级设置

HTTP/1.1 无法为重要的资源指定优先级，每个 HTTP 请求都是一视同仁。

在继续讨论 HTTP/2 的新功能之前，先把 HTTP/1.1 的问题列出来是有意义的。因为 HTTP/2 的某些新功能就是为了解决上述某些问题而产生的。

二进制分帧层

HTTP/2 是基于帧的协议。采用分帧是为了将重要信息封装起来，让协议的解析方可以轻松阅读、解析并还原信息。

而 HTTP/1.1 是以文本分隔的。解析 HTTP/1.1 不需要什么高科技，但往往速度慢且容易出错。你需要不断地读入字节，直到遇到分隔符 CRLF 为止，同时还要考虑不守规矩的客户端，它只会发送 LF。

解析 HTTP/1.1 的请求或响应还会遇到以下问题：

1. 一次只能处理一个请求或响应，完成之前不能停止解析。
2. 无法预判解析需要多少内存。

HTTP/2 有了帧，处理协议的程序就能预先知道会收到什么，并且 HTTP/2 有表示帧长度的字段。

帧结构

+-----------------------------------------------+
 |                 Length (24)                   |
 +---------------+---------------+---------------+
 |   Type (8)    |   Flags (8)   |
 +-+-------------+---------------+-------------------------------+
 |R|                 Stream Identifier (31)                      |
 +=+=============================================================+
 |                   Frame Payload (0...)                      ...
 +---------------------------------------------------------------+

由于 HTTP/2 是分帧的，请求和响应都可以多路复用，有助于解决类似类似队头阻塞的问题。

帧类型

多路复用

在 HTTP/1.1 中，如果客户端想发送多个并行的请求，那么必须使用多个 TCP 连接。

而 HTTP/2 的二进制分帧层突破了这一限制，所有的请求和响应都在同一个 TCP 连接上发送：客户端和服务器把 HTTP 消息分解成多个帧，然后乱序发送，最后在另一端再根据流 ID 重新组合起来。

这个机制为 HTTP 带来了巨大的性能提升，因为：

• 可以并行交错地发送请求，请求之间互不影响；
• 可以并行交错地发送响应，响应之间互不干扰；
• 只使用一个连接即可并行发送多个请求和响应；
• 消除不必要的延迟，从而减少页面加载的时间；
• 不必再为绕过 HTTP 1.x 限制而多做很多工作；

流

HTTP/2 规范对流的定义是：HTTP/2 连接上独立的、双向的帧序列交换。如果客户端想要发出请求，它会开启一个新流，然后服务器在这个流上回复。 由于有分帧，所以多个请求和响应可以交错，而不会互相阻塞。流 ID 用来标识帧所属的流。

客户端到服务器的 HTTP/2 连接建立后，通过发送 HEADERS 帧来启动新的流。如果首部需要跨多个帧，可能还会发送 CONTINUATION 帧。该 HEADERS 帧可能来自请求或响应。 后续流启动的时候，会发送一个带有递增流 ID 的新 HEADERS 帧。

消息

HTTP 消息泛指 HTTP 请求或响应，消息由一或多个帧组成，这些帧可以乱序发送，然后再根据每个帧首部的流 ID 重新组装。

一个消息至少由 HEADERS 帧（它初始化流）组成，并且可以另外包含 CONTINUATION 和 DATA 帧，以及其他的 HEADERS 帧。

HTTP/1.1 的请求和响应部分都分成消息首部和消息体两部分；HTTP/2 的请求和响应分成 HEADERS 帧和 DATA 帧。

优先级

把 HTTP 消息分解为很多独立的帧之后，就可以通过优化这些帧的交错和传输顺序，进一步提升性能。

通过 HEADERS 帧和 PRIORITY 帧，客户端可以明确地和服务器沟通它需要什么，以及它需要这些资源的顺序。具体来讲，服务器可以根据流的优先级，控制资源分配（CPU、内存、带宽），而在响应数据准备好之后，优先将最高优先级的帧发送给客户端。

流量控制

在同一个 TCP 连接上传输多个数据流，就意味着要共享带宽。标定数据流的优先级有助于按序交付，但只有优先级还不足以确定多个数据流或多个连接间的资源分配。

为解决这个问题，HTTP/2 为数据流和连接的流量控制提供了一个简单的机制：

• 流量控制基于每一跳进行，而非端到端的控制；
• 流量控制基于 WINDOW_UPDATE 帧进行，即接收方广播自己准备接收某个数据流的多少字节，以及对整个连接要接收多少字节；
• 流量控制窗口大小通过 WINDOW_UPDATE 帧更新，这个字段指定了流 ID 和窗口大小递增值；
• 流量控制有方向性，即接收方可能根据自己的情况为每个流乃至整个连接设置任意窗口大小；
• 流量控制可以由接收方禁用，包括针对个别的流和针对整个连接。

HTTP/2 连接建立之后，客户端与服务器交换 SETTINGS 帧，目的是设置双向的流量控制窗口大小。除此之外，任何一端都可以选择禁用个别流或整个连接的流量控制。

服务器推送

HTTP/2 新增的一个强大的新功能，就是服务器可以对一个客户端请求发送多个响应。换句话说，除了对最初请求的响应外，服务器还可以额外向客户端推送资源，而无需客户端明确地请求。

为什么需要这样一个机制呢？通常的 Web 应用都由几十个资源组成，客户端需要分析服务器提供的文档才能逐个找到它们。那为什么不让服务器提前就把这些资源推送给客户端，从而减少额外的时间延迟呢？服务器已经知道客户端下一步要请求什么资源了，这时候服务器推送即可派上用场。

另外，客户端也可以拒绝服务器的推送。

首部压缩

HTTP/1.1 存在的一个问题就是臃肿的首部，HTTP/2 对这一问题进行了改进，可以对首部进行压缩。 在一个 Web 页面中，一般都会包含大量的请求，而其中有很多请求的首部往往有很多重复的部分。

例如有如下两个请求：

:authority: unpkg.zhimg.com
:method: GET
:path: /za-js-sdk@2.16.0/dist/zap.js
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9
cache-control: no-cache
pragma: no-cache
referer: https://www.zhihu.com/
sec-fetch-dest: script
sec-fetch-mode: no-cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36

:authority: zz.bdstatic.com
:method: GET
:path: /linksubmit/push.js
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9
cache-control: no-cache
pragma: no-cache
referer: https://www.zhihu.com/
sec-fetch-dest: script
sec-fetch-mode: no-cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36

从上面两个请求可以看出来，有很多数据都是重复的。如果可以把相同的首部存储起来，仅发送它们之间不同的部分，就可以节省不少的流量，加快请求的时间。

HTTP/2 在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送。

下面再来看一个简化的例子，假设客户端按顺序发送如下请求首部：

Header1:foo
Header2:bar
Header3:bat

当客户端发送请求时，它会根据首部值创建一张表：

如果服务器收到了请求，它会照样创建一张表。 当客户端发送下一个请求的时候，如果首部相同，它可以直接发送这样的首部块：

62 63 64

服务器会查找先前建立的表格，并把这些数字还原成索引对应的完整首部。

性能优化

使用 HTTP/2 代替 HTTP/1.1，本身就是一种巨大的性能提升。 这小节要聊的是在 HTTP/1.1 中的某些优化手段，在 HTTP/2 中是不必要的，可以取消的。

取消合并资源

在 HTTP/1.1 中要把多个小资源合并成一个大资源，从而减少请求。而在 HTTP/2 就不需要了，因为 HTTP/2 所有的请求都可以在一个 TCP 连接发送。

取消域名拆分

取消域名拆分的理由同上，再多的 HTTP 请求都可以在一个 TCP 连接上发送，所以不需要采取多个域名来突破浏览器 TCP 连接数限制这一规则了。

参考资料

• HTTP权威指南
• HTTP/2基础教程
• SSL/TLS 握手过程详解
• 互联网安全之数字签名、数字证书与PKI系统
• 计算机网络（第7版）
• Web性能权威指南

更多文章，敬请关注

Ajax

Ajax 是最常规的建立异步 HTTP 请求的方式。你可以使用 HTTP POST 方法来发送数据，以及使用 HTTP GET 来接收数据。我们先来看看如何发起一个  GET  请求。这里我会用到一个免费在线的 REST API 工具 JSONPlaceholder，它可以用来给开发者返回随机的 JSON 格式数据。

要在 Ajax 中发起一个 HTTP 调用，你需要初始化一个新的 XMLHttpRequest() 方法，指定 URL 端点和 HTTP 方法（在本例中为 GET）。最后，使用  open()  方法将两者结合起来，并调用  send()  方法执行请求。

我们可以在  XMLHTTPRequest.onreadystatechange  的事件监听器中输出 HTTP 请求结果日志到控制台中，这个事件监听器会在  readystatechanged  事件发生的时候触发。

const Http = new XMLHttpRequest();
const url='https://jsonplaceholder.typicode.com/posts';
Http.open("GET", url);
Http.send();

Http.onreadystatechange = (e) => {
  console.log(Http.responseText)
}

如果你查看浏览器的控制台，上面的代码会返回一组 JSON 格式的数组数据。但是我们怎么知道请求已经完成了呢？换句话说，我们应该怎样处理 Ajax 的响应数据呢？

onreadystatechange  有两个方式可以让我们可以检测到当前请求的状态，  readyState  和  status。

如果  readyState  等于 4，意味着请求已经完成了。readyState  这个属性可以有 5 种状态值。你可以点击这里了解更多。

除了直接通过 JavaScript 创建 Ajax 调用，还有其他的非常有效的创建 HTTP 调用的方法，比如 jQuery 中的方法  $.Ajax。现在我们就来讨论这些方法。

jQuery 方法

jQuery 有很多可以轻松处理 HTTP 请求的方法。为了能使用到这些方法，你需要在你的项目中引入 jQuery 库。

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>

$.ajax

jQuery 的 ajax 是发起 HTTP 调用最简单的方法之一。

$.ajax 方法拥有很多参数，有的是必要的，有的是可选的。它有两个回调选项  success  和  error  ，可以用来处理接收到的响应数据。

$.get 方法

$.get 方法用来执行 GET 请求，它接收两个参数：端点和回调函数。

$.post

**$.post**  方法是另一种向服务端发送数据的方法，它接收三个参数：url，你想要发送的数据，和一个回调函数。

$.getJSON

$.getJSON  方法仅用于获取 JSON 格式的数据。它接收两个参数：url  和一个回调函数。

jQuery 有以上这些方法用来给远端服务器发起请求或者传递数据。不过你最终可以将所有的这些方法都用一个方法来实现:  $.ajax  , 正如下面示例中所看到的那样。

fetch

fetch  是一个功能强大的新的 web API，它能够让你发起异步的请求。实际上，  fetch  是最好的也是我最喜欢用的发起 HTTP 请求的方式之一。它会返回一个 “Promise”，这也是 ES6 中最强大的特性之一，如果你不是很熟悉 ES6，可以看看这篇文章了解一下。Promise 可以让我们用一种更聪明的方式处理异步请求。让我们来看一下  fetch  从技术上来说是如何工作的。

fetch  函数接收一个必要参数：端点  URL。在下面的示例中它也有其它的可选参数：

如你所见，fetch  在创建 HTTP 请求方面有很多优势。你可以从这里了解更多。另外，在 fetch 之上也有一些其他的模块和插件可以让我们给服务端发送请求或者从服务端接收请求，比如axios

Axios

Axios 是一个开源的创建 HTTP 请求的库，它提供了许多好用的特性，让我们来看一看它是如何用的吧。

Usage:

首先，你需要引入 Axios。这里有两种方式将 Axios 引入你的项目。

第一种，你可以使用 npm 进行安装:

npm install axios --save

然后你需要引入它:

import axios from 'axios'

第二种，你可以使用 CDN 来引入 axios：

<script src="https://unpkg.com/axios/dist/axios.min.js"></script>

使用 axios 创建请求:

基于 Axios，你可以使用  GET  和  POST  来向服务端请求数据和发送数据。

GET:

axios 需要一个必填参数，当然你也可以提供第二个可选参数。这个示例调用一些数据作简单的查询。

POST:

Axios  返回一个 “Promise”。如果你对 Promise 比较熟悉的话，你应该知道用 Promise 可以用来执行并行请求。这里你就可以用 axios 在同一时间运行多个并行请求。

Axios 还提供了一些其他的方法和选项，你可以在这里具体看看。

Angular HttpClient

Angular 有它自己的和 Angular 应用一起运行的 HTTP 模块。它使用到了  RxJS  库来处理异步请求，同时还提供了许多用来执行 HTTP 请求的选择。

使用 Angular HttpClient 来发起一个服务端调用

为了能使用 Angular HttpClient 来发起一个请求，我们需要将代码运行在一个 Angular 应用中。所以我这里就创建了一个。如果你对 Angular 不是很熟悉的话，可以看一下我的文章  20分钟内学会如何创建你的第一个 Angular 应用  。

我们需要做的第一件事儿是在  app.module.ts  中引入  HttpClientModule  模块。

然后，我们需要创建一个服务来处理请求。你可以使用  Angular CLI  很容易的创建一个服务。

ng g service  FetchdataService

再然后，我们需要在  fetchdataService.ts  服务中的引入 HttpClient 并且将其注入到构造器中。

在  app.component.ts  文件中引入  fetchdataService。

//import
import { FetchdataService } from './fetchdata.service';

最后，调用这个服务并运行。

app.component.ts:

你可以在  Stackblitz  上看到这整个示例。

总结

我们刚刚了解了在 JavaScript 中最常用的创建 HTTP 请求的几种方式。

感谢你的阅读。如果你喜欢的话，点击 "关注"，然后可以在  Twitter  上找到我。

顺便说一下，我最近与一群强大的软件工程师一起为我的一个移动应用程序工作。该组织非常出色，产品交付速度非常快，比我所合作的其他公司和自由职业者要快得多，我认为我可以诚实地推荐他们用于其他项目。如果您想与我联系，请给我发送电子邮件。

原文：Here are the most popular ways to make an HTTP request in JavaScript，作者：Said Hayani

因为开发过大大大大大大量的 Restful API ，越来越厌烦那种一成不变的代码组织方式。

以 egg为例，要增加一个接口，需要经历繁琐的操作

[路由里注册] ---> [编写 controller] ---> [编写 service] 

哪怕我只是想实现一个 a+b => c！

除此以外，我还调研过某几个比较大的 函数计算 服务商，看看有没有什么好的途径，可以更简便地进行简单接口开发。

让人很失望，天下技术一大抄，它们无一例外都是这样的开发模型：

function(event, context, callback) {}
或者
function(event, context) {}

于是你不得不这样写你的代码

// 举例
function(event, context, callback) {
  const { a, b } = event.arguments; 
  callback(a+b);
}

这算个什么鬼函数？！

你必须改变第一直觉，严格按照厂商的要求来写你的代码，并且寄希望于有人站出来要求它们统一event、context这些旁系知识的实现细节。

并且！

你很难进行本地测试！

你要构造奇奇怪怪的对象作为参数。哪怕只是测试两数相加.

OK! 如果你说，稍微学习一下，其实还是可以用的吧。

可以用就是我们的追求吗？要 应然 还是 实然 ？

难倒我们期望的样子，不应该是这样吗？

// 🔥🔥
function (a, b) {
	return a+b;
}

正文开始：

所以，如果我需要实现一个 a+b => c 的接口，

我期望我的代码是这样的：

export default (a: number, b: number): number => {
  return a + b;
}

我期望我的测试是这样的：

describe('sum', () => {
  it('1+1 is 2', () => {
    assert.equal(sum(1,1), 2);
  });
});

十分明显好吗！

它并不受制于具体平台实现；

它并不需要你学习其他旁系知识，只关注你的功能本身；

它方便测试，因为它就是一个不能再普通的函数；

它可复用！

多说无益，直接动手

export default (a: number, b: number): number => {
  return a + b;
}

有过上一篇的基础，我们直奔抽象语法树：

// 由于只有一行代码，结构就简单多了
{
	type: 'ExportDefaultDeclaration',
	declaration: {
		type: 'ArrowFunctionExpression',
		params: [ 下文展开 ],
		body: { 不重要 },
		returnType: { 下文展开 }
	}
}

我们还是从整体上先看一下，上面这个结构充分表达了源代码的意图：

• 这是一个 export default声明 (ExportDefaultDeclaration )
• 声明的内容是一个箭头函数 (ArrowFunctionExpression )

考虑到，我们希望从这一行代码里面，生成提供HTTP服务的基础代码，

那么我们的主要任务就是，从以上有限的信息当中，提取出Restful API需要的基础信息：

• Method
• Path
• 请求参数

🤖 我们一个一个来解决：

1. HTTP Method

   首选是要确定这个接口，最终通过什么 Method对外服务，在这里源代码并不能提供任何有效信息。

   那么我们就默认用 GET 好了

   🔥其他的 Method，会在文末提及

2. Path， 或者叫 URL

   对于一个接口来说，这也是十分关键的信息，这里我们有两种解决方案

   • 使用函数名，如果有的话
   • 使用当前文件名

   我们姑且把 URL 定为 /sum 好了

   🔥 笔者的一个实验性项目里，使用的是文件名

3. 请求参数

   如果说前面两点都是基于约定，或者一些简单的手段，

   那么在请求参数这个环节，我们必须上价值了，要让 ast 发挥作用！

   我们先展开一下上面 ast 里关于函数参数的部分：

   // params 部分
   [
   	{
   		name: 'a',
   		typeAnnotation: { type: 'TSNumberKeyword' }
   	},
   	{
   		name: 'b',
   		typeAnnotation: { type: 'TSNumberKeyword' }
   	},
   ]
   

   好家伙，可以拿到参数名 a 和 b 了

   结合 TSNumberKeyword 信息，我们甚至能笃定这两个参数是数字类型。

   知道类型，就可以做参数校验！

   🔥通过原始函数定义的参数类型生成 http 参数校验逻辑，比起手工编写 Joi 配置要可靠得多。

   等等，还有一个问题没解决

   参数名和参数类型都有了，缺的就是参数位置以及 content-type 。

   约定大法好，根据多年开发总结得出：

   总所周知， GET 请求的参数就放在 queryString 里吧。

   至于 content-type 统一使用 application/json 不接受反驳

齐活了

结合上面收集到的信息，我们可以想象最终的场景是：

• step 1 : 按上面的方式，编写一个不能再普通的函数
• step 2: 使用我们编写好的工具，运行这个函数
• step 3: 可以通过 http://127.0.0.1:3000/sum?a=11&b=22 来访问这个接口，并且得到结果 33

通过这个截图可知，虽然实现细节比较多，但是可行性是没问题的。

并且笔者已经做出了一个实验性项目。

如果对这种模式比较感兴趣，欢迎前来讨论，在这里就不打广告了。

FAQ 环节

• 更多的 HTTP_METHOD 怎么办？总不能都用 GET 吧

  目前我选能用的方案是，如果没有声明，就用一个默认的 GET，

  因为要尽量选一个能覆盖 90% 情况的作为默认值。

  当我需要使用其他 Method ，我的方案是显式指定，比如

  export const method = 'POST';
  
  export default (a: number, b: number): number => {
    return a + b;
  }
  

  这个方案可以使信息更紧凑，同时不影响函数逻辑跑本地单元测试。

• 上面提到的入参参数位置，什么时候在 queryString，什么时候在其他？

  遵从大多数的案例，GET 的情况下使用 queryString， 其他情况下在 body

  当然还有完全自定义的方案，为避广告嫌疑就不展开了，基本原则还是不影响函数核心逻辑和单元测试。

• 上面提到的 入参参数类型 ，有什么应用场景？

  有了这个信息，如果你喜欢 Joi， 应该能很容易生成参数校验的代码了。

  或者有自己想法的话，和我一样，自己实现一套 validator 也不是什么难事。