POST 是否应该仅用于 RESTful 服务器中的创建类型 API？
Should POST be only used for creation type APIs in a RESTful server?
RESTful（或任何）类型的服务器是否应该仅使用 POST 路由来创建数据？例如，如果我说我需要从我们的服务器获取一些过滤数据，有些人会建议将这些条件放在 POST 路由的主体中。
但是，一些开发人员还建议将这些条件放在 GET 路由中，并使用 url 参数或 url 查询来获取数据。后者的相同开发人员也会告诉我，每当调用 POST 路由时，就应该创建一些东西，例如在数据库中。
对我来说，使用 GET 进行查询以保留它似乎是更好的做法 RESTful。我想知道将 POST 路由排除在基本查询之外有多重要，为什么？ （如果它很重要的话）
按照 Fielding 的定义，REST 的主要特征是 uniform interface。
要有一个统一的界面，你需要标准化你正在使用的协议元素。
HTTP 方法的通用标准是 RFC 7231. It defines GET for retrieval of representations, which can include “filtered data”. It defines GET to be safe and cacheable。
假设您正在编写一个通用RESTful客户端。您可以假设 GET 将检索请求的 URL 的表示。您可以缓存对 GET 的响应。您可以重试 GET 错误请求（因为它是安全的）。这些都非常有用。
但是 POST 被定义为通用的、包罗万象的方法。它不仅缺乏自己的语义，而且 RFC 7231 说（强调我的）：
The POST method requests that the target resource process the
representation enclosed in the request according to the resource's
own specific semantics.
因此，在您的通用 RESTful 客户端中，您无法对 POST 进行任何假设，因此您无法使用它做任何有用的事情。
所以 GET 是统一接口的一部分，而 POST 不是。从这个意义上说，GET 是“更多 RESTful”。
也就是说，您可以为 POST 请求设计一个新标准，例如Content-Type: application/data-filter，具有有用且定义明确的语义。它会与 RFC 7231 的上述文本相矛盾，但无论如何，如果您有足够多的人同意您（可能在您的组织内），您就会再次获得统一的界面。
顺便说一句，有人试图 standardize a SEARCH method 来做这样的事情。这将作为一个统一的接口（与标准化的 Content-Type 结合）工作得很好。不幸的是，该提案已停滞不前，因此您可能不应该使用 SEARCH.
RESTful（或任何）类型的服务器是否应该仅使用 POST 路由来创建数据？例如，如果我说我需要从我们的服务器获取一些过滤数据，有些人会建议将这些条件放在 POST 路由的主体中。
但是，一些开发人员还建议将这些条件放在 GET 路由中，并使用 url 参数或 url 查询来获取数据。后者的相同开发人员也会告诉我，每当调用 POST 路由时，就应该创建一些东西，例如在数据库中。
对我来说，使用 GET 进行查询以保留它似乎是更好的做法 RESTful。我想知道将 POST 路由排除在基本查询之外有多重要，为什么？ （如果它很重要的话）
按照 Fielding 的定义，REST 的主要特征是 uniform interface。
要有一个统一的界面，你需要标准化你正在使用的协议元素。
HTTP 方法的通用标准是 RFC 7231. It defines GET for retrieval of representations, which can include “filtered data”. It defines GET to be safe and cacheable。
假设您正在编写一个通用RESTful客户端。您可以假设 GET 将检索请求的 URL 的表示。您可以缓存对 GET 的响应。您可以重试 GET 错误请求（因为它是安全的）。这些都非常有用。
但是 POST 被定义为通用的、包罗万象的方法。它不仅缺乏自己的语义，而且 RFC 7231 说（强调我的）：
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.
因此，在您的通用 RESTful 客户端中，您无法对 POST 进行任何假设，因此您无法使用它做任何有用的事情。
所以 GET 是统一接口的一部分，而 POST 不是。从这个意义上说，GET 是“更多 RESTful”。
也就是说，您可以为 POST 请求设计一个新标准，例如Content-Type: application/data-filter，具有有用且定义明确的语义。它会与 RFC 7231 的上述文本相矛盾，但无论如何，如果您有足够多的人同意您（可能在您的组织内），您就会再次获得统一的界面。
顺便说一句，有人试图 standardize a SEARCH method 来做这样的事情。这将作为一个统一的接口（与标准化的 Content-Type 结合）工作得很好。不幸的是，该提案已停滞不前，因此您可能不应该使用 SEARCH.