[기술공부]Http method개념과 종류

allnight5·2023년 4월 25일

기술공부

목록 보기

21/33

Http의 개념
Get
Post
Put
Delete
Patch
기타 메소드
HTTP 메소드들의 속성들

Http 메소드 개념

목록으로
HTTP 메소드란 웹 브라우저와 웹 서버가 통신할 때 사용되는 방식으로, 클라이언트가 서버에 요청(request)을 보낼 때 사용되는 명령어입니다.

Get

목록으로
GET 메소드는 주로 데이터를 읽거나(Read) 검색(Retrieve)할 때에 사용되는 메소드이다.
GET 방식은 요청하는 데이터를 URL의 파라미터에 담아서 보내는 방식입니다. 예를 들어, 검색어를 입력하여 검색 결과를 요청하는 경우 URL에 검색어를 담아서 보내게 됩니다

GET요청이 성공적으로 이루어진다면 XML이나 JSON과 함께 200 (Ok) HTTP 응답 코드를 리턴한다.
하지만 GET 요청이 성공했지만 응답 본문에 내용이 없는 경우 서버는 204 (No Content) HTTP 상태 코드를 반환하며
203(Non-Authoritative Information)는 캐시된 응답을 클라이언트에게 반환할 때 사용됩니다
에러가 발생하면 주로 404 (Not found)상태코드나 400 (Bad request) 상태코드가 반환 됩니다.
클라이언트가 요청한 리소스에 접근할 권한이 없거나 인증 정보가 유효하지 않은 경우 에는 403(Forbidden) 이라는 상태코드가 반환됩니다.

HTTP 명세에 의하면 GET 요청은 오로지 데이터를 읽을 때만 사용되고 수정할 때는 사용하지 않는다.
GET 요청은 idempotent 하다. 왜냐하면 변경된것이 여러번 같은 요청을 하더라도 변경 사항이 없으며 같은 요청을 여러 번 하더라도 변함없이 항상 같은 응답을 받을 수 있다.
데이터를 변경하는 연산에 사용하면 안된다.

GET 방식은 URL에 담을 수 있는 데이터의 크기에 제한이 있습니다.
따라서, 대용량 데이터를 전송하는 경우에는 GET 방식을 사용할 수 없습니다.

Post

목록으로
정의
POST 메소드는 주로 새로운 리소스를 생성(create)할 때 사용된다. 조금 더 구체적으로 POST는 하위 리소스(부모 리소스의 하위 리소스)들을 생성하는데 사용된다. 성공적으로 creation을 완료하면 201 (Created) HTTP 응답을 반환한다.

같은 POST 요청을 반복해서 했을 때 항상 같은 결과물이 나오는 것을 보장하지 않는다
두 개의 같은 POST 요청을 보내면 같은 정보를 담은 두 개의 다른 resource를 반환할 가능성이 높다. 두 개의 요청이 서로 다른 리소스가 되기 때문이다.
그로인하여 POST 요청은 멱등(idempotent) 하지 않다.

보내는 데이터 크기에 제한이 있는 GET방식과는 달리
POST 방식은 요청 본문에 데이터를 담아서 보내기 때문에 데이터의 크기에 제한이 없습니다.

예시

POST /user
body : {date : "example"}
Content-Type : "application/json"

데이터를 생성하는 것이기 때문에 요청시에 Body 값과 Content-Type 값을 작성해야한다. 해당 예시는 JSON을 통해서 작성된 예시이다.

Delete

목록으로
정의
DELETE 메서드는 지정된 리소스를 삭제합니다.

데이터를 삭제하는 것이기 때문에 요청시에 Body 값과 Content-Type 값이 비워져있다.
URL을 통해서 어떠한 데이터를 삭제할지 파라메터를 받는다.
데이터 삭제에 성공한다면 Body 값 없이 성공 응답만 보내게 된다.
멱등성이 보장됩니다.

Put

목록으로
정의
PUT 메소드는 클라이언트에서 서버로 데이터를 전송할 때 사용됩니다.

이 때, 전송된 데이터는 서버에서 기존 데이터와 교체됩니다. PUT 메소드는 데이터의 전체를 수정할 때 사용됩니다.

PUT 요청은 idempotent(멱등) 합니다.
동일한 PUT 요청을 여러 번 호출하면 항상 동일한 결과가 생성됩니다.

PUT은 요청된 리소스를 대체하기 때문에, 여러 번 수행하더라도 항상 같은 리소스에서 대체 됩니다. 따라서, 여러 번 수행하더라도 시스템의 상태나 데이터는 변하지 않습니다.
그러므로 PUT은 멱등하다고 말합니다.

Patch

목록으로
PUT은 지정한 데이터를 전부 수정하는 Method이지만 PATCH는 정보의 일부분이 변경되는 방법입니다.

put과는 다르게 멱등성이 보장 되지 않는데
put의 경우 put요청들만 들어올 경우 순차적으로 처리가 됩니다.
그러니까 결국 put은 마지막 요청에 의해서 리소스 전체가 바뀌는 것으로 멱등성이 보장됩니다.

하지만 patch의 경우 patch요청들이 다른 일부분을 수정하게 되므로 순차적으로 처리 하지 않습니다.나는 a랑 b를 바꾸는데 다른 요청은 c랑 바꾼다는 것이죠 그래서 a랑 b만 바뀐 결과가 저장되고나서 c가 저장되어야 하는데 바로 a와 b와 c를 바꾼 데이터가 저장되는 겁니다.

그러니까 어떤 것이 바꾼 것 인지 알수 없기때문에 멱등성이 보장 되지 않습니다.

기타 메소드

목록으로
HEAD : GET과 동일하지만 메시지 바디를 제외하고 반환
OPTIONS : 대상 리소스에 대한 통신을 설정하는 데 사용
CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

HTTP 메소드들의 속성들

목록으로

메소드	안전	멱등	캐시O
GET	✔	✔	✔
POST	X	X	✔
PUT	X	✔	X
DELETE	X	✔	X
PATCH	X	X	✔
HEAD	✔	✔	✔
CONNECT	X	X	X
OPTIONS	✔	✔	X
TRACE	✔	✔	X

안전 Safe

호출해도 리소스를 변경하지 않는 특성

목록으로

아래 멱등성에서 등장하는 같은요청이란??

PUT이면 PUT요청만 계속 들어가는것이고 GET이면 GET요청이 들어가는 것이고 POST면 POST요청이 계속해서 들어가지만 요청하는 내용은 바뀌어 있는것도 같은 요청이라고합니다.

그러니 같은 요청이라는데 왜 멱등성이 달라진다는 거지? 라는 의문은 여기서 해결하고 가시기 바랍니다.

POST 요청이 3번 들어왔다. 댓글을 작성하는데
1번 POST는 "안녕"이고 2번 POST는 "그만" 3번 POST는 "여기가 끝이야"로 3개의 POST요청이 들어간 것으로 이것을 내용은 다르지만 같은요청 이라고한다.
POST의 경우 동일한 요청을 여러 번 보내면 각각 다른 리소스가 생성됩니다. 따라서 멱등성을 보장할 수 없습니다.

아래 멱등성에서 등장하는 리소스란??

REST API에서 리소스는 일반적으로 데이터의 표현이며
'/users' 엔드포인트는 모든 사용자 데이터의 컬렉션을 나타내는 리소스입니다. '/users/1'은 데이터베이스에서 사용자 ID가 1인 행을 나타내는 리소스일 수 있습니다. 따라서 리소스는 데이터의 표현으로 볼 수 있으며, 이것이 RESTful 아키텍처에서의 중요한 개념 중 하나입니다.

간단히 이해한다면 요청에 의해서 변경되는 테이블의 행 또는 테이블 자체, 또는 다른 종류의 데이터를 의미
PUT /users/1 요청으로 이름 속성을 "Alice"에서 "Bob"으로 수정하면,
결과적으로 서버에는 {"id": 1, "name": "Bob", "age": 25}와 같은 전체 리소스가 저장됩니다.
이름 속성을 "Alice"에서 "Bob"으로 수정하는 요청과
나이를 35로 수정하는 요청이
동시 요청이 들어온다고 하더라도
{"id": 1, "name": "Bob", "age": 25}
{"id": 1, "name": "Alice", "age": 35}
각자의 처리로 되기 때문에 요청에 대한 결과가 하나의 결과로 처리되어 어떤 것이 저장한지 모르거나 리소스가 변경되지 않습니다.

반면, PATCH 메소드는 일부 속성만 수정할 수 있으므로, 위의 예시에서 PATCH 메소드를 사용해 "이름"과 "나이" 속성을 수정하려면, 요청 내용은
{"name": "Bob", "age": 30}과 같이 변경됩니다.
이 경우, 서버는 {"id": 1, "name": "Bob", "age": 30}와 같이 변경된 리소스를 저장합니다. 이렇게 끝난다면 PATCH는 멱등성을 보장했을 것입니다.

하지만 만약 PUT에서 하던 이름의 변경과 나이의 변경에 대한 요청이
PATCH 요청으로 처리되어 중복으로 전송된다면,
서버에서는 각각의 PATCH 요청이 순차적으로 적용되어 최종적으로
{"id": 1, "name": "Bob", "age": 35}와 같은 리소스가 저장됩니다.
이 경우 PATCH 메소드는 멱등성이 보장되지 않습니다.

목록으로

멱등성 Idempotent

아무리 임의의 값에 연산을 여러번 적용하더라도 같은 결과값을 반환한다.

외부 요인으로 중간에 리소스가 변경되는 것을 고려하지 않고 해당 요청을 기준으로 고려한다

올바르게 구현한 GET, PUT, DELETE 메소드는 멱등성을 지녀야 한다.

예)
DELETE /members/100 → 200
DELETE /members/100 → 404
DELETE를 여러 번 호출하면 응답 코드는 달라질 수 있지만, 100번 member가 삭제된 것은 동일

여기서 의문일수 있다. POST는 새로 생성하면. 테이블에 변화가 생긴다면 멱등성이 깨지는 것 일 탠데. 리소스가 달라졌으니 말이다. 왜 DELETE는 멱등하다고 하느냐? POST는 같은 요청이 들어올 때마다 새로운 리소스가 계속해서 생성되지만. DELETE는 같은 요청이 들어온다면 그 리소스 하나만 가지고 결과를 도출 하기 때문이다.

목록으로

캐시 가능 Cacheable

응답 결과를 서버에 캐시 해서 사용해도 되는 메소드
GET, HEAD, POST, PATCH가 가능합니다.

캐시는 요청이 들어왔고 이미 전에 처리해둔 데이터를
다시 DB 조회를 하고 찾아서 보내주는 것이 아닌
이전에 동일한 요청을 저장해 두었다가 캐시에서 동일하게 요청한 것을 보내주는 것입니다.
(여기서 똑같은 요청이 들어오기전에 수정작업이나 삭제 작업 등이 일어났다면 캐시가 일어나지 않습니다. 일어난다면 아직 서버에서 그 변경내용에 대한 캐시 처리를 하지않아 최신 정보가 아닌것입니다.)

캐시는 주로 IN-MEMORY 형태이나 캐시 종류에 따라 다르지만 한번
요청한 데이터를 캐시라는 형태로 캐시 데이터 저장소에
가지고 있다가 동일한 요청이 들어왔을때 서버는 로직을
처리하지 않고 그 자료를 바로 보내줌으로써 서버의
부하가 줄어들고 불필요한 DB 조회나 연산 등의
작업을 줄일 수 있게 됩니다.