--- title: "#19.7 HTTP method 共同研究會 - DELETE/OPTION" tags: Meetups date: 2022-05-12 --- ## See [RFC-7231 DELETE](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.5) The DELETE method requests that the origin server remove the association between the target resource and its current functionality. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation on the URI mapping of the origin server rather than an expectation that the previously associated information be deleted. DELETE 方法要求來源伺服器移除目標資源與他目前功能的關聯。 這個方法跟 `rm` 指令是類似的，不是刪除原本的資料，而是移除來源伺服器裡面的 URI 對應某個資源。 If the target resource has one or more current representations, they might or might not be destroyed by the origin server, and the associated storage might or might not be reclaimed, depending entirely on the nature of the resource and its implementation by the origin server (which are beyond the scope of this specification). Likewise, other implementation aspects of a resource might need to be deactivated or archived as a result of a DELETE, such as database or gateway connections. In general, it is assumed that the origin server will only allow DELETE on resources for which it has a prescribed mechanism for accomplishing the deletion. 如果資源有一個或多個狀態，它可能會，也可能不會被來源伺服器銷毀，並且關聯的儲存也不會刪除，要看資源性質和來源伺服器的實作而定。 有可能是停用或封存，會是 DELETE 的效果。 一般來說會假設伺服器只允許具有刪除機制的資源做刪除。 如果是DELETE請求, 對資料庫來說也能是將資料從該表移除並做archieve, 或者做軟刪除deactive. 對Gateway來說能把connection做release. Relatively few resources allow the DELETE method -- its primary use is for remote authoring environments, where the user has some direction regarding its effect. For example, a resource that was previously created using a PUT request, or identified via the Location header field after a 201 (Created) response to a POST request, might allow a corresponding DELETE request to undo those actions. Similarly, custom user agent implementations that implement an authoring function, such as revision control clients using HTTP for remote operations, might use DELETE based on an assumption that the server's URI space has been crafted to correspond to a version repository. 相較比較少資源使用 DELETE 方法，它用在編修的情境下。 比方說用 PUT 或 POST 新增資源後，可以把對應的資源刪除，達到復原效果 If a DELETE method is successfully applied, the origin server SHOULD send a 202 (Accepted) status code if the action will likely succeed but has not yet been enacted, a 204 (No Content) status code if the action has been enacted and no further information is to be supplied, or a 200 (OK) status code if the action has been enacted and the response message includes a representation describing the status. 202 表示操作可能會成功, 但就收到還沒執行 204 沒內容且操作已經執行, 並且沒必要提供回傳進一步的訊息 200 已經執行, 且回傳訊息會包含狀態的表示 A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request. Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see Section 4.4 of [RFC7234]). --------------- ## [4.3.7. OPTIONS](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.7) The OPTIONS method requests information about the communication options available for the target resource, at either the origin server or an intervening intermediary. This method allows a client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action. OPTIONS 方法是用來請求對目標資源的通訊選項 An OPTIONS request with an asterisk ("\*") as the request-target (Section 5.3 of [RFC7230]) applies to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "\*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 conformance (or lack thereof). 如果對來源伺服器而不是資源, 發OPTIONS請求並攜帶```*```, 代表整個服務器, 通常指的是對服務器做ping的測試, 或是測試http代理伺服器是否符合http/1.1等等的版本. If the request-target is not an asterisk, the OPTIONS request applies to the options that are available when communicating with the target resource. 如果對請求的對象沒攜帶```*```, 那必須是針對目標資源詢問, 能對該資源的通訊的可用方式. [Example](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS) ： ``` OPTIONS /index.html HTTP/1.1 OPTIONS * HTTP/1.1 ``` A server generating a successful response to OPTIONS SHOULD send any header fields that might indicate optional features implemented by the server and applicable to the target resource (e.g., Allow), including potential extensions not defined by this specification. The response payload, if any, might also describe the communication options in a machine or human-readable representation. A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP. A server MUST generate a Content-Length field with a value of "0" if no payload body is to be sent in the response. Example ``` OPTIONS /resources/post-here/ HTTP/1.1 Host: bar.example Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Connection: keep-alive Origin: https://foo.example Access-Control-Request-Method: POST Access-Control-Request-Headers: X-PINGOTHER, Content-Type ``` A client MAY send a Max-Forwards header field in an OPTIONS request to target a specific recipient in the request chain (see Section 5.1.2). A proxy MUST NOT generate a Max-Forwards header field while forwarding a request unless that request was received with a Max-Forwards field. A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing the representation media type. Although this specification does not define any use for such a payload, future extensions to HTTP might use the OPTIONS body to make more detailed queries about the target resource. Responses to the OPTIONS method are not cacheable.