補充 - HTTP methods

HTTP Methods

HTTP Methods 意義
GET 讀取資源 (safe & idempotent)
HEAD 與 GET 功能相同,但不會回傳 Body
POST 新增資源
PUT 替換資源 (idempotent) Replace (Create or Update)
DELETE 刪除資源 (idempotent)
  • RFC2616: Hypertext Transfer Protocol (HTTP)
  • RFC2617: HTTP Authentication: Basic and Digest Access Authentication

延伸閱讀

HTTP Methods 定義

The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed to share the same semantics for separately extended clients and servers. >>> HTTP/1.1: Method Definitions

HTTP 1.1 定義了以下一系列的常見的 methods,為了分離 clients 和 servers,雖然這些 method 可以被擴充、添加,但不可以假定共用相同的語意。

This document has been superseded. In 2014, RFC2616 was replaced by multiple RFCs (7230-7237)

延伸閱讀

Safe and Idempotent Methods

資料來源:Hypertext Transfer Protocol - Wikipedia

Safe Methods

Safe methods are HTTP methods that do not modify resources. For instance, using GET or HEAD on a resource URL, should NEVER change the resource.

它不會改變 resources 的 HTTP mehtods,我們就叫它是 Safe mehtods。例如 GET 或 HEAD 從不改變 resources。

Idempotent(冪等) Methods

An idempotent HTTP method is a HTTP method that can be called many times without different outcomes. It would not matter if the method is called only once, or ten times over. The result should be the same. Again, this only applies to the result, not the resource itself. This still can be manipulated like an update-timestamp, provided this information is not shared in the (current) resource representation.

一個 HTTP mehtod 可以被呼叫多次,每次都會取得相同的結果,我們就叫它是 idempotent HTTP method。不論被呼叫一次或多次,結果都會相同。這只適用在回應結果,不是指 resource 本身。仍然可以控制像是 update-timestamp,提供此資訊但不能在資源呈現時共享。

資料來源: REST cook book - What are idempotent and/or safe methods?

Cacheable Methods

Request methods can be defined as "cacheable" to indicate that responses to them are allowed to be stored for future reuse; for specific requirements see RFC7234. In general, safe methods that do not depend on a current or authoritative response are defined as cacheable; this specification defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD.

當 Request methods 可以被 cache 並允許儲存作為未來重複使用就叫 Cacheable Methods,規範在 RFC7234。一般來說,多數的 cache 指支援 GET 和 HEAD,但 Safe Methods 跟 Cacheable Methods 沒有絕對關係。

Compare GET vs. POST

  • GET 可以被加入瀏覽器歷史紀錄,反之 POST 不行。
  • GET 可以被加入瀏覽器書籤,反之 POST 不行。
  • POST 相對比 GET 安全性高,因為不會被 cache,也不會顯示在瀏覽器歷史紀錄中,及 server log 中。
  • GET 不能用來傳送需要安全性高的資料
  • GET 應該只被用在取得資料
  • GET 有資料長度的限制,因為 URL 的長度最大只資源 2048 characters。
  • GET 參數會顯示在 URL 上,反之 POST 不會。

資料來源: w3c school - HTTP Methods: GET vs. POST

問題

  • 應該用 HTTP GET 來傳的參數,用 HTTP POST 來傳,會導致什麼問題?
  • 反之,應該用 HTTP POST 來傳的參數,用 HTTP GET 來傳,會導致什麼問題?

Compare PUT vs. PATCH

  • PUT: 更新全部內容,若資料之前不存在,則新增一筆。
  • PATCH: 這是後來才追加的 mehtod,更新資源部份內容。

問題

  • HTTP PUT 會用到的情境是?

Compare PUT vs. POST

延伸閱讀

RFC 7230 ~ 7237

更動範圍說明(只列出重點項目)

  1. 對如何處理不應該出現的空格進行了規定,將能修復 HTTP Response Splitting 漏洞
  2. 每服務器兩個連接的限制被移除
  3. 不再支持 HTTP/0.9
  4. 默認編碼不再是 ISO-8859-1
  5. 服務器不再被強制要求處理所有 Content-* 請求頭內容
  6. PUT請求頭禁止使用Content-Range
  7. 如果引用頁不存在,建議在請求頭裡使用 about:blank 這個URI,以便對「沒有引用頁」和「我不想發送引用頁」加以區別
  8. 狀態碼 204, 404, 405, 414 和 501 現在可以緩存了(cachable)
  9. 狀態碼 301 和 302 現在允許用戶代理(user-agent)將請求方式從POST改為GET。雖然原標準不允許,但人們其實早就在這樣做了,標準適應現實,這是個很好的例子。
  10. 請求頭的 Location 現在可以包含相對URI和片段標識符(fragment identifiers)
  11. Content-MD5 被移除

延伸閱讀

results for ""

    No results matching ""