使用POST在REST应用程序中调用任意处理 [英] Using POST to invoke arbitrary processing in REST applications
问题描述
我一直在阅读广泛推荐的REST介绍并遇到以下情况声明：
I have been reading the widely recommended introduction to REST and came across the following statement:
POST，通常意味着创建新资源，可以也可用于调用任意处理，因此既不安全也不是幂等。
POST, which usually means "create a new resource", can also be used to invoke arbitrary processing and thus is neither safe nor idempotent.
任意处理等字样既不是[ie不安全使 POST 在有选择时听起来不如 PUT 安全。这样吗？如果是这样，最好是在可能的情况下优先选择 PUT 而不是 POST ？
Words like arbitrary processing and neither [i.e. not] safe make POST sounds less secure than PUT when there is a choice. Is this so? If so, is it best practice to prefer PUT over POST when possible?
我原本希望在这个评价很高的问题中突出显示任何安全问题。但是，在一个排名很低的答案中，只提到一点安全性。我模糊地得到了幂等的理论价值，但我确实得到了安全的实用价值。我想很多人都是这样的。所以我猜测 POST 周围没有特别的安全问题，尽管任意处理。
I would have expected to find any security concerns highlighted in this highly-rated question. However, there is only a single mention of security in a quite lowly-ranked answer. I vaguely get the theoretical value of idempotence, but I definitely get the practical value of security. I imagine a lot of people are like that. So I'm guessing that there are no particular security concerns around POST, despite the arbitrary processing.
哪里可以找到比猜测更可靠的保证？
Where can I find more solid reassurance than guesswork?
推荐答案
在此上下文中，safe与安全性无关
在HTTP方法的上下文中， safe与安全无关。基本上，安全意味着只读。
如果你有有关HTTP / 1.1协议的任何问题， RFC 7231 是最适合您的参考。该文档定义了HTTP协议的语义和内容。
If you have any questions regarding the HTTP/1.1 protocol, the RFC 7231 is the best reference for you. The document defines the semantics and the content of the HTTP protocol.
看看它对安全方法的看法：
Have a look at what it says about safe methods:
如果请求方法的定义语义为
基本上是只读的，则视为安全;即，由于
对目标资源应用安全方法，客户端不会请求并且
不期望原始服务器上的任何状态更改。 [...]
Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. [...]
在本规范定义的请求方法中， GET ， HEAD ，
OPTIONS ， TRACE 方法定义为安全。 [...]
Of the request methods defined by this specification, the GET, HEAD,
OPTIONS, and TRACE methods are defined to be safe. [...]
现在，看看有关幂等方法的内容：
Now, have a look at what it says about idempotent methods:
如果对
的预期影响是多个相同的服务器，则请求方法被视为幂等使用该方法的请求是
与单个此类请求的效果相同。在本规范定义的请求方法
中， PUT ， DELETE ，以及安全请求方法
是幂等的。 [...]
A request method is considered "idempotent" if the intended effect on
the server of multiple identical requests with that method is the
same as the effect for a single such request. Of the request methods
defined by this specification, PUT, DELETE, and safe request methods
are idempotent. [...]
总结一下，HTTP方法被归类为关注：
Summarizing, the HTTP methods are classified as following:
+---------+------+------------+
| Method | Safe | Idempotent |
+---------+------+------------+
| CONNECT | no | no |
| DELETE | no | yes |
| GET | yes | yes |
| HEAD | yes | yes |
| OPTIONS | yes | yes |
| POST | no | no |
| PUT | no | yes |
| TRACE | yes | yes |
+---------+------+------------+
使用 POST 动词
POST 通常用于创建新资源。但对于不应使用其他方法执行的操作，它也是 catch-all动词。
Using the POST verb
POST is commonly used to create a new resource. But it's also a catch-all verb for operations that should not be executed using the other methods.
使用 POST 非安全操作（非只读）和非幂等操作（多个相同的请求可能有不同的效果）。
Use POST for non safe operations (not read-only) and for non idempotent operations (multiple identical requests may have different effects).
在下一页中，您将找到有关选择的好答案 PUT 或 POST 在REST应用程序中：
In the following page, you'll find great answers regarding choosing PUT or POST in REST applications:
PUTvsPOSTin REST
下面你会找到HTTP / 1.1协议的当前参考：
Below you'll find the current references for the HTTP/1.1 protocol:
- RFC 7230: Message Syntax and Routing
- RFC 7231: Semantics and Content
- RFC 7232: Conditional Requests
- RFC 7233: Range Requests
- RFC 7234: Caching
- RFC 7235: Authentication
这篇关于使用POST在REST应用程序中调用任意处理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
