根据Rest,如果需要检索一些数据,我们应该使用GET,如果要创建资源,则使用POST。
但是,如果我们必须使用多个参数(超过7-8),或者UUID列表,那么我们不应该使用POST而不是GET吗?
为了避免:
谢谢。
发布于 2020-08-02 18:01:00
使V.柱休息
当到达的语义符合用例时,使用GET;换句话说,当您试图检索某个资源的最新表示的副本时。
当没有其他标准化方法支持所需的语义时,使用POST。
您可以将POST用于任何东西,但是您放弃了使用更专门的方法的优势--通用组件能够执行智能的事情,因为它们理解请求的语义。例如,GET具有安全语义,这意味着通用组件知道它可以在用户需要资源之前预先获取资源的表示,或者在没有从服务器获得响应时自动重复请求。
HTTP提供给您的是通用POST方法改进的可扩展集合,添加了更具体的约束,以便通用组件可以利用结果属性。
URL的复杂性
URL中的复杂性并不是什么大问题,对于一般用途的组件来说,URL只是一个不透明的字节序列,恰好符合特定的生产规则。在大多数情况下,web请求的有效目标uri被视为原子单位,因此,“对人类来说似乎很复杂的事情根本不打扰机器(例如,查看从google主页提交搜索时使用的URL )。”
URL长度,这可能会在未来限制我们
我们关心的是URL长度。RFC 3986并不限制URI的长度,但是如果长度远远超出规范,一些通用组件的实现就会失败。因此,您可能不希望在请求的查询部分中包括莎士比亚未删节作品的url编码副本。
未来纳入任何新领域的范围
再说一次,这里没有太大的区别。向URI模板添加新的可选元素与将新的可选元素添加到消息模板实际上没有什么不同。
我们可能会冒着暴露帕拉姆斯的危险
我们还需要小心敏感信息--就机器而言,URI是一个标识符;没有特殊的理由担心特定的字节序列。这意味着URI可以在rest中公开(在客户端历史记录或书签列表中,在服务器访问日志中)。将敏感信息限制在消息正文上,可以减少数据超出其预期用途的转义机会。
注意,REST和利用不同的HTTP方法并不是完成有用工作的唯一方法。SOAP (以及最近的gRPC)决定使用不同的权衡集合更好--实际上,减少了HTTP,而不是应用程序本身。
根据休息,我们应该..。如果它正在创建资源,请使用POST。
这是对REST的错误解释。这是一个非常普遍的解释,但不正确。帖子的语义由RFC 7231定义;它意味着,而不是其他东西。
关于职位只用于创建的建议是一种误导,而不是简单化。我找到的最早的参考资料是Prescod在2002年发表的一篇博客文章;当然,随着Rails的到来,它变得非常流行。
但是回想一下: REST是万维网的建筑风格。HTML是web上使用的最常见的超文本媒体类型,它只支持两种HTTP方法;GET (用于从服务器获取资源表示)和POST (用于完成其他一切)。
发布于 2020-08-02 15:44:58
如果您有敏感数据(如用户名和密码),则也应该使用POST,这些数据最好以表单参数(键值对)编码。
https://stackoverflow.com/questions/63217885
复制相似问题