看到這篇在講 HTTP (& HTTPS) 裡面 GET 與 POST 的差異，剛好把一些標準的定義拿出來翻一翻，算是複習基本概念：「Get safe」。
第一個基本概念主要是 idempotence (& idempotent)，重複被呼叫不會造成狀態的再次改變：
Idempotence ([...]) is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application.
數學定義是這樣跑：
An element x of a magma (M, •) is said to be idempotent if:
x • x = x.
If all elements are idempotent with respect to •, then • is called idempotent. The formula ∀x, x • x = x is called the idempotency law for •.
這點在 HTTP 標準 (RFC 7231) 裡面的定義也類似：
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.
第二個基本概念是 Safe method (也是在同樣的 RFC 裡被提到)，主要的思想是 read-only，這也是文章作者的標題要講的事情：
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. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.
然後標準的 HTTP method 是有定義的：
+---------+------+------------+---------------+
| Method | Safe | Idempotent | Reference |
+---------+------+------------+---------------+
| CONNECT | no | no | Section 4.3.6 |
| DELETE | no | yes | Section 4.3.5 |
| GET | yes | yes | Section 4.3.1 |
| HEAD | yes | yes | Section 4.3.2 |
| OPTIONS | yes | yes | Section 4.3.7 |
| POST | no | no | Section 4.3.3 |
| PUT | no | yes | Section 4.3.4 |
| TRACE | yes | yes | Section 4.3.8 |
+---------+------+------------+---------------+
不過文章裡面提到的第一個例子並沒有很好，POST 不保證 safe 沒錯，但不代表 safe operation 就不能用 POST。
這邊用 URI resource 的概念 (以及 SEO？) 或是用 Post/Redirect/Get 的概念來說明會比較好：
<form method="get" action="/search">
<input type="search" name="term">
不過文章後續提到的問題的確就是我自己都會犯錯的問題：
“Log out” links that should be forms with a “log out” button—you can always style it to look like a link if you want.
“Unsubscribe” links in emails that immediately trigger the action of unsubscribing instead of going to a form where the POST method does the unsubscribing. I realise that this turns unsubscribing into a two-step process, which is a bit annoying from a usability point of view, but a destructive action should never be baked into a GET request.
這兩個動作都會造成 server 端的狀態改變，不應該用 GET，而我自己常常忘記第一個... 這邊其實可以用 form 產生 POST 需求，並且用 css 效果包起來，達到看起來跟一般的連結一樣。
寫起來讓自己多一點印象，之後避免再犯一樣的錯誤...
