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请求，如果默认情况下使用POST，则不会缓存GET请求。因此，每次都会向服务器触发一个新请求。这样会导致很多连接，资源等。

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

4）POST-VS-GET-如果您使用POST，则可以包含RequestBody，而不能包含GET请求，因此最好遵循GET来获取资源数据

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

2 个答案: