0

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

我的团队已决定对所有休息动词使用 POST,因为 GET、PUT、DELETE 会在 url 中公开 id。

我的团队认为,在 url 中暴露任何类型的数据都不是一个好主意,即使 id 不是直接的数据库 id。

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

这是我们计划为 REST API 做的唯一区别。你怎么看?

4

3 回答 3

4

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

我会断言,如果您将自己限制为 POST,那么几乎不可能获得 RESTful 系统的好处。话虽如此,考虑到您只针对 HTML5 客户端,您可能不需要大多数 REST 优势。执行 Json-RPC 可能足以满足您的需求。

但是,我仍然认为为了虚假的安全感而放弃 GET 是一个坏主意。您的帖子正文就像 URI 中的 id 一样容易被某些中介访问。

于 2012-09-04T14:36:11.360 回答
1

您应该按照预期使用 HTTP,以便获得堆栈的全部好处。不同的动词有不同的语义是有原因的。

您可能会觉得 POST 比 GET all you want 更安全,但这是一个错误的前提。

你从谁那里保护这些数据?中间人?这就是 HTTPS 解决的问题。

您是否从最终用户那里保护它?那些可以随时下载您的整个应用程序并在空闲时研究源代码的人?或者通过右键单击查看页面的源代码并查看您的有效负载的全部布局?或者只是打开浏览器调试器并查看您的所有流量?你想从那些人那里保护它?

POST 不会向任何人隐瞒任何事情。

于 2012-09-04T14:49:19.257 回答
0

您可能应该看看这篇文章,因为它几乎解释了 https 为您做了什么。所以问题是:你想保护谁的 URL?它可能在浏览器历史记录中或对站在用户身后的人可见,但对在线收听的任何人都看不到。

于 2012-09-04T14:46:49.020 回答