我正在设计一个运行模拟的API端点，并返回结果。
此端点是否应接受GET请求或POST请求？
我该怎么办？
答案 0 :(得分：3)
此端点是否应接受GET请求或POST请求？
我收到了一些好消息。 REST并不关心。
Riddle：你会如何在网站上提供这项服务？
你可能有一些普遍感兴趣的登陆页面，在那个页面上你会添加一个链接＆＃34;点击这里试试模拟器！＆＃34;当消费者关注该链接时，您将提供描述模拟所需参数的表单的表示，其中包含端点和操作的标识符。消费者将提交填写的表格，向您的终端发送模拟器参数的表示。
超媒体API的工作方式相同;客户端不应该知道端点或使用什么方法。它需要知道的是如何从表格的表示中获取该信息。
如果您有超媒体API，则可以更改端点，或在http方法之间来回切换，而无需更新客户端以匹配。
没有破坏性的副作用（根本没有副作用）。所以POST看起来也不合适。
我为你带来了更多好消息。使用POST fine 。当前使用POST的权限不是堆栈溢出，而是RFC-7231
POST方法请求目标资源根据资源自身的特定语义处理请求中包含的表示。例如，POST用于以下功能（以及其他功能）：
- 将数据块（例如输入HTML表单的字段）提供给数据处理流程
完美。除非你明确地这样做，否则它不可缓存。它包含用于将用户重定向到可缓存的数据表示的工具，适用于有意义的情况。
所做的是与浏览器或中间组件通信，可以安全地重试丢失的邮件。
以下是菲尔丁在2009
中对此所说的话当该信息对应于潜在资源时，使用POST进行信息检索并不是RESTful，因为该使用会阻止安全的可重用性以及具有URI的网络效应。
POST仅在某些其他方法非常适合的情况下使用时才成为问题：例如，检索应该是某种资源（GET）的表示的信息，完全替换表示（PUT），或者任何其他标准化的方法告诉中间人比“这可能会改变一些东西更有价值”。其他方法对中介更有价值，因为他们说的是如何自动处理故障以及中间缓存如何优化他们的行为。 POST没有这些特征，但这并不意味着我们可以没有它。 POST在HTTP中提供了许多有用的用途，包括“此操作不值得标准化”的一般目的。
HTTP没有为包含有效负载的safe操作指定方法。它 确实指定包含有效负载的idempotent方法; PUT。使用PUT是异常，因为它与＃34;创建＆＃34;的通常理解并不完全一致。或者＆＃34;更新＆＃34;，但只要您注意标识符，我认为它有效。
PUT并不意味着存储。我必须在webdav和相关列表中重复这一百万次。 HTTP定义了通信的预期语义 - 每个方的期望。该协议没有定义任何一方如何满足这些期望，并且它确实无法阻止服务器对其自身资源拥有绝对权限。
我理解这是指：
来自RFC 7231：
成功的回复仅表示用户代理的意图是在原始服务器处理时实现的。
此外，200 status代码的定义为您提供了一些空间
对于本规范定义的方法，有效载荷的预期含义可概括为：
- 获取目标资源的表示
- PUT，DELETE表示行动的状态;
所以我认为这是一个选项，经详细审查后，可能比POST或GET更适合您的特定情况。
答案 1 :(得分：1)
我相信有这样的事情你会想要POST个请求，并在Response或JSON XML中向用户返回一些内容。我现在使用API为网站发送POST，我从Response获取数据，并且我有很多参数我已经过了。< / p>
答案 2 :(得分：0)
首先，应该重构和简化此API端点。无论是GET还是POST或其他什么，都应避免使用带有大量参数的HTTP请求。具有大量参数的请求意味着两个模块之间的紧密耦合 - 客户端必须非常仔细地组装以满足服务器的要求。此外，使用大量参数的请求会带来文档和培训的成本。
也就是说，如果无法避免许多参数，必须是POST 。原因是：虽然它应该是GET（语义上），但在这种情况下GET是不可行的 - 所有参数的请求都超过了查询字符串的最大限制。浏览器可能会截断查询字符串并中断请求。
总之，这不是关于我应该做什么的问题，而是关于我必须做什么的问题，除非API端点已经过优化。< / p>