出于安全原因，在REST API中为每个HTTP谓词使用POST是否合适？

Question

我正在开发一个企业网络应用程序。我们的应用程序将仅以https部署到生产中。我们正在编写REST API，仅由我们的html 5客户端使用（不适用于其他人）

我的团队已决定对所有其余动词使用POST，因为GET，PUT，DELETE会在网址中公开id。

我的团队认为，在网址中公开任何类型的数据都不是一个好主意，即使id不是直接数据库ID。

似乎每个人都同意使用POST http方法进行GET，PUT，DELETE并将http_method作为参数传递，并使用参数决定要执行的操作。

这是我们计划为REST API做的唯一区别。你觉得怎么样？

Answer 1

通过避免使用GET，您失去了使用缓存的能力。隐藏正文中的资源ID很可能会导致您违反“资源标识”约束。这将使链接/超媒体变得更加困难。

我认为，如果你将自己局限于POST，几乎不可能获得RESTful系统的好处。话虽如此，考虑到您只针对HTML5客户端，您可能不需要大部分REST优势。做Json-RPC可能足以满足您的需求。

然而，我仍然认为丢弃GET是因为虚假的安全感是一个坏主意。您的帖子正文也很容易被一些中间人作为URI中的ID访问。

Answer 2

您应该按预期使用HTTP，这样您就可以获得堆栈的全部好处。不同的动词有不同的语义。

你可以觉得POST比GET更安全，但这是一个错误的前提。

您从谁那里保护这些数据？男人在中间？这就是HTTPS解决的问题。

您是否从最终用户那里获得了保障？那些可以随时下载整个应用程序并在闲暇时间学习源代码的人？或者通过右键单击查看页面的来源并查看您的所有荣耀中的有效负载？或者只需打开浏览器调试器并观看所有流量？你试图从这些人那里获得保障吗？

POST不会隐藏任何人的任何内容。

Answer 3

你应该看看this post，因为它几乎解释了https为你做了什么。所以问题是：你想保护谁来保护URL？它可能位于浏览器历史记录中，也可能对站在用户后面的人可见，但对于在线收听的任何人都不可见。