[HTTP] methods

안녕하세요, Einere입니다.

(ADblock을 꺼주시면 감사하겠습니다.)

---

오늘은 HTTP의 method의 종류에 대해 알아보도록 하겠습니다.

 

 

GET

Use GET requests to retrieve resource representation/information only – and not to modify it in any way. As GET requests do not change the state of the resource, these are said to be safe methods. Additionally, GET APIs should be idempotent, which means that making multiple identical requests must produce the same result every time until another API (POST or PUT) has changed the state of the resource on the server.
If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.
For any given HTTP GET API, if the resource is found on the server then it must return HTTP response code 200 (OK) – along with response body which is usually either XML or JSON content (due to their platform independent nature).
In case resource is NOT found on server then it must return HTTP response code 404 (NOT FOUND). Similarly, if it is determined that GET request itself is not correctly formed then server will return HTTP response code 400 (BAD REQUEST).

GET 요청은 특정 자원을 조회하기 위해 사용합니다.

특정 자원을 절대로 변경시켜서는 안됩니다. 따라서, 자원의 상태를 변경시키지 않으므로 안전한 메소드라고 할 수 있습니다.

함수와 같이, 같은 입력에 대해서는 같은 자원을 응해야 합니다.

만약 요청이 자원을 생성하는 요청이라면, 자원을 생성하는 코드를 응답하는 것이 아니라, 생성된 자원 자체를 응답합니다.

요청한 자원이 서버에서 발견된 경우, 반드시 응답코드 200과 함께 응답합니다. 만약 발견되지 않은 경우, 응답코드 404를 응답합니다.

요청이 올바르지 않은 형식인 경우, 응답코드 400을 응합니다.

 

 

POST

Use POST APIs to create new subordinate resources, e.g. a file is subordinate to a directory containing it or a row is subordinate to a database table. Talking strictly in terms of REST, POST methods are used to create a new resource into the collection of resources.
Ideally, if a resource has been created on the origin server, the response SHOULD be HTTP response code 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.
Many times, the action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either HTTP response code 200 (OK) or 204 (No Content) is the appropriate response status.
Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields.
Please note that POST is neither safe nor idempotent and invoking two identical POST requests will result in two different resources containing the same information (except resource ids).

POST 요청은 새로운 하위 자원을 생성하는데 사용합니다.

만약 해당 자원이 이미 만들어져 있다면, 자원을 응답코드 201과 함께 응답합다.

요청에 특정 자원을 생성하지 않는 경우라면, 응답코드 200 혹은 204로 응답합니다.

요청이 적절한 캐시 컨트롤 혹은 헤더 필드 만료를 포함하지 않는다면, 응답은 캐싱되지 않습니다.

POST 요청은 안전하지도 않고 멱등적이지도 않습니다. (즉, 같은 요청에 대해 다른 응답을 할 수 있습니다.)

 

 

PUT

Use PUT APIs primarily to update existing resource (if the resource does not exist then API may decide to create a new resource or not).
If a new resource has been created by the PUT API, the origin server MUST inform the user agent via the HTTP response code 201 (Created) response and if an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

PUT 요청은 현존하는 자원을 갱신하기 위해 사용합니다. (현존하지 않는다면 생성하거나 생성하지 않을 수 있습니다.)

만약 자원을 새로 생성한다면, 반드시 응답코드 201을 응답해야 합니다.

자원을 갱신한다면 응답코드 200 혹은 204로 응답합니다.

요청이 캐시를 통과하고, 요청 URI가 하나 이상의 캐싱된 엔티티를 식별한다면, 캐싱된 엔티티들을 반드시 오래된 자원으로 취급해야 합니다. 즉, 요청이 캐시를 통과했다는 것은, 이전과 다른 새로운 요청을 했다는 뜻입니다. 그리고 새로운 요청에 대해 서버가 어느 자원을 요청했는지 찾았다면, 반드시 새롭게 갱신된 엔티티를 응답합니다. 클라이언트에서는 새롭게 갱신된 엔티티를 응답받으므로, 캐싱된 엔티티와 응답으로 받은 엔티티는 서로 값이 다릅니다. 따라서 캐싱된 엔티티는 오래된 데이터로 취급해야 합니다.

요청 자체는 캐싱되지만, 요청에 대한 응답은 캐싱되지 않습니다. 즉, 서버가 다음에 올 동일한 요청을 대비해서 응답할 내용을 미리 준해두지 않습니다.

 

 

DELETE

As the name applies, DELETE APIs are used to delete resources (identified by the Request-URI).
A successful response of DELETE requests SHOULD be HTTP response code 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has been queued, or 204 (No Content) if the action has been performed but the response does not include an entity.
DELETE operations are idempotent. If you DELETE a resource, it’s removed from the collection of resource. Repeatedly calling DELETE API on that resource will not change the outcome – however calling DELETE on a resource a second time will return a 404 (NOT FOUND) since it was already removed. Some may argue that it makes DELETE method non-idempotent. It’s a matter of discussion and personal opinion.
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

DELETE 요청은 uri로 식별된 자원을 삭제하기 위해 사용합니다.

해당 자원을 성공적으로 삭제했고, 스테이터스를 명시할 자원과 함께 응답해야 한다면, 응답코드 200으로 응답합니다.

해당 요청이 큐되었다면 응답코드 202로 응답합니다.

해당 요청이 자원을 성공적으로 삭제했고, 어떠한 자원도 없이 응답해야 한다면, 응답코드 204로 응답합니다.

특정 자원에 대한 반복적인 DELETE 요청은 응답을 변화시키지 않습니다. (단, 두번째 요청은 응답코드 404를 반환할것입니다.)

요청이 캐시를 통과하고, uri가 하나 이상의 캐싱된 객체를 식별한다면, 해당 객체들을 반드시 오래된 자원으로 취급해야 합니다. (뭔말이여)

요청에 대한 응답은 캐싱되지 않습니다.

 

 

PATCH

HTTP PATCH requests are to make partial update on a resource. If you see PUT requests also modify a resource entity so to make more clear – PATCH method is the correct choice for partially updating an existing resource and PUT should only be used if you’re replacing a resource in its entirety.
Please note that there are some challenges if you decide to use PATCH APIs in your application:

PATCH 요청은 특정 자원을 부분적으로 갱신하기 위해 사용합니다. 반면에 PUT 요청은 특정 자원을 전체적으로 대체하고 싶은 경우에 적합합니다.

 

 

위 메소드들 외에도 CONNECT, OPTIONS, TRACE, HEAD가 있습니다.

 

요약

methods	CRUD	safe	entire collection (/users)	specific item (/users/13)
GET	Read	O	200	200, 404
POST	Create	X	201	Avoid using POST on single resource
PUT	Update / Replace	X	404	200, 204, 404
PATCH	Partial Update / Modify	X	404	200, 204, 404
DELETE	Delete	X	404	200, 404

 

 

 

참고

https://restfulapi.net/http-methods/

HTTP Methods [ RESTful APIs Verbs ] – REST API Tutorial