在设计API时坚持适当的HTTP请求类型有多重要？

Question

通常在设计API时我会尝试坚持以下结构：

GET: /resources (get multiple resources)
POST: /resource (create a single resource)
GET: /resource/:id (get a single resource)
PUT: /resource/:id (update a single resource)
DELETE: /resource/:id (delete a single resource)

但有时当你“获取”数据时，传入的参数开始增长超出了查询字符串中可以包含的范围。例如，在我提供的GET: /resources示例中，可能有许多过滤器要应用于您选择的资源。

在这种情况下，是否可以开始使用POST，以便您可以在请求正文中包含参数？摆脱对上述结构的依从性有什么缺点？

Answer 1

在这种情况下，是否可以开始使用POST，以便您可以在请求正文中包含参数？

是的，也就是说有权衡。

摆脱对上述结构的依从性有什么缺点？

它会干扰通用组件智能参与协议的能力。

GET请求有safe语义;代理可以利用这个来预先获取资源，爬虫可以自由地浏览内容，等等。

成功的不安全方法invalidate缓存条目。当你想要同一资源的多个表示时，这会变得很尴尬;通过POST获取一个表示将从缓存中驱逐相同资源的其他表示。

如果我们真正想要的只是RPC，我们可以用POST完成所有工作。例如，请参阅“SOAP”，其中内置于有效负载中的所有消息传递和HTTP仅用作哑通道。

Answer 2

1）REST是一种类似于HTTP通信的设计模式。遵循REST总是好的，特别是当您将API暴露给公共使用或浏览器到服务器通信时。

2）即使没有正确的REST模式，您也可以编写HTTP请求，但如果浏览器与服务器通信，则会导致不必要的问题。由于大多数现代浏览器都是使用REST标准设计的，因此他们会很好地理解这种模式。默认情况下，GET请求将被缓存，而不是GET，如果您默认使用POST，它将不会缓存。因此，每次都会向服务器发出新请求。所以它会导致很多连接，资源等。

3）GET - Word本身为您提供仅用于获取资源的含义。同样，POST和PUT用于创建记录，DELETE用于删除等。

4）POST-VS-GET - 如果你使用POST你可以包含RequestBody而在GET请求中你不能。最好跟随GET获取资源数据