REST API使用POST而不是GET

2018-06-16 00:03:06

假设一个服务提供了一些我可以使用的funcionality：

GET /service/function?param1=value1&param2=value2

说我可以在POST查询中使用它是否正确？

POST /service/function { param1 : value1, param2 : value2 }

这两个查询是一样的吗？我可以在任何情况下使用第二个变体，或者文档应该明确说我可以同时使用GET和POST查询？

如果不使用这些方法进行构建以独立调用，则无法使用POST或GET使用API 。就像你的API说的那样

/service/function?param1=value1&param2=value2

通过使用GET方法访问。然后，如果创建者未将其指定为POST方法，则无法使用POST方法调用它。如果你这样做，你可能会得到405 Method not allowed状态。

通常在POST方法中，您需要以指定的格式发送内容，该格式在content-type标头中描述为ex。 application/json for json数据。

之后，请求主体在服务器端得到反序列化。因此，您需要从客户端传递序列化的数据，并由服务开发人员决定。

但是一般来说，当服务器向客户端返回一些数据并且对服务器没有任何影响时使用GET ，而POST用于在服务器上创建一些资源。所以通常它不应该是一样的。

只是为了回顾一下， REST具有某些开发者为了使其RESTful应遵循的特性：

什么是REST？

根据维基百科：

REST体系结构风格描述了应用于体系结构的以下六个约束条件，同时使各个组件的实现免于设计：

客户端 - 服务器：服务器不关心用户界面或用户状态，因此服务器可以更简单，更具可扩展性。

无状态：客户端 - 服务器之间的通信进一步受限于在请求之间没有客户端上下文存储在服务器上。

可缓存：响应必须隐式或显式地将自己定义为可缓存或不可缓存，以防止客户端重新使用陈旧或不适当的数据来响应进一步的请求。

分层系统：客户通常无法确定它是直接连接到最终服务器还是直接连接到中间服务器。中介服务器可以通过启用负载平衡和提供共享缓存来提高系统可扩展性。

按需代码（可选）：服务器可以通过传输可执行代码来临时扩展或自定义客户端的功能。

统一接口：下面讨论的客户机和服务器之间的统一接口简化和分离了体系结构，使得每个部分能够独立演变。（即HTTP GET，POST，PUT，PATCH，DELETE）

所以用户Daniel Vasallo在解决这个问题的过程中做了很好的工作：理解REST：动词，错误代码和认证 ：

处理Collection URI时：http://example.com/resources/

GET：列出集合的成员，并附上其成员URI以供进一步导航。例如，列出所有待售汽车。

PUT：含义定义为“用另一个集合替换整个集合”。

POST：在由集合自动分配ID的集合中创建一个新条目。创建的ID通常包含在此操作返回的数据中。

DELETE：含义定义为“删除整个集合”。

说我可以在POST查询中使用它是否正确？ ...

这两个查询是一样的吗？我可以在任何情况下使用第二个变体，或者文档应该明确说我可以同时使用GET和POST查询？

如果您正在编写一个普通的旧的RPC API调用，只要处理服务器端在两个调用之间没有区别，就可以在技术上互换。但是，为了使调用成为RESTful，通过GET方法调用端点应具有明确的功能（即从POST方法（即创建新资源）获取资源）。

附注：有一些关于POST是否应该被允许用来更新资源的讨论......尽管我没有对此进行评论，但我只是告诉你一些人在这一点上有问题。

由于以下原因，我使用POST正文来处理任何不平凡的行业应用程序：

安全性 - 如果我们对查询字符串和https使用GET，查询字符串可以保存在服务器日志中并作为引用链接转发。这两个现在都可以通过服务器/网络管理员以及用户在离开您的应用程序后转到的下一个域来显示。因此，如果我们发送包含机密PII数据（例如客户名称）的查询，则可能不希望这样。

URL最大长度 - 不是一个大问题，但有些浏览器对长度有限制。因此，如果我们的网址中有多个项目，如查询，分页，要返回的字段等....

Post默认情况下不是缓存。有人说缓存是需要的; 然而，对于该确切客户在缓存超时之前将发生的完全相同的搜索条件，多长时间一次？

顺便说一句，我也把字段返回到我的POST正文，因为我可能不希望公开我的字段名称。安全就像洋葱; 许多层，让我们哭泣！

链接地址: http://www.djcxy.com/p/45343.html