探索 RESTful GET 操作中请求主体的使用

利用 GET 请求中的请求正文来增强 RESTful 服务

使用 Node.js 和 Express 进行服务器端实现

const express = require('express');
const bodyParser = require('body-parser');
const app = express();
const port = 3000;
// Allow express to use body-parser as a middleware
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));
// Mock database for demonstration
let mockData = [{ id: 1, name: 'Item 1' }, { id: 2, name: 'Item 2' }];
// GET endpoint with request body
app.get('/api/items', (req, res) => {
  // Use request body for filtering or sorting if it exists
  if (req.body.sort) {
    return res.json(mockData.sort((a, b) => a.name.localeCompare(b.name)));
  }
  res.json(mockData);
});
app.listen(port, () => {
  console.log(`Server running on port ${port}`);
});

使用 GET 请求通过自定义请求主体获取数据

使用 JavaScript Fetch API 进行客户端实现

const fetchDataWithBody = async () => {
  const response = await fetch('http://localhost:3000/api/items', {
    method: 'GET',
    headers: {
      'Content-Type': 'application/json',
    },
    // Although not standard, some servers might support body in GET requests
    body: JSON.stringify({ sort: 'name' })
  });
  if (!response.ok) {
    throw new Error('Network response was not ok');
  }
  const data = await response.json();
  console.log(data);
};
fetchDataWithBody().catch(console.error);

有关带有正文的 GET 请求的常见问题

1. 问题： 从技术上讲是否可以在 GET 请求中包含正文？
2. 回答： 是的，从技术上讲，可以在 GET 请求中包含正文，但这不是标准做法，并且可能会导致某些客户端和服务器出现意外行为。
3. 问题： 为什么标准 RESTful 实践不建议在 GET 请求中使用主体？
4. 回答： 标准实践建议不要在 GET 请求中使用主体来保持请求的简单性、清晰度和可缓存性，遵守 REST 架构风格的无状态和幂等性质。
5. 问题： 在 GET 请求中包含正文会影响缓存机制吗？
6. 回答： 是的，由于缓存机制通常会关闭 URL，因此在 GET 请求中包含正文可能会影响有效缓存响应的能力。
7. 问题： 代理和防火墙如何响应带有正文的 GET 请求？
8. 回答： 某些代理和防火墙可能不希望 GET 请求包含正文，并且可能会剥离正文或完全阻止请求，从而导致不可预测的行为。
9. 问题： 在 GET 请求中使用主体是否有任何实际场景是有益的？
10. 回答： 虽然罕见、复杂的查询场景或避免长 URL 的需要可能会促使在 GET 请求中使用主体，但为了兼容性通常首选替代方法。

反思带有正文内容的 GET 请求

总之，在 GET 请求中嵌入主体与既定的 RESTful 约定存在争议。虽然该技术提供了一种在不混乱 URI 的情况下传递复杂或广泛的查询参数的解决方法，但它带来了重大挑战，包括代理、防火墙和缓存的潜在互操作性问题，这些代理、防火墙和缓存的设计目的不是预期或处理 GET 请求中的正文内容。此外，这种方法可能会使 GET 操作的语义复杂化，偏离支撑 REST 架构风格的无状态、可缓存和幂等原则。考虑到这些因素，建议开发人员仔细权衡利弊。使用查询参数、设计更具体的资源或在适当的情况下采用其他 HTTP 方法可能会为复杂的数据传输需求提供更强大和兼容的解决方案，而不会偏离 REST 原则。最终，遵守广泛接受的标准可确保在庞大的网络技术生态系统中具有更高的兼容性和可预测性。