[Network] HTTP Method

해당 글은 VSFe 깃허브 레포를 참고하여 작성한 글입니다. (아래 출처에 표기)

 

✅ HTTP Method에 대해 설명해 주세요.

HTTP(Hypertext Transfer Protocol) Method는 클라이언트-서버 구조에서 요청(request)과 응답(response)이 이루어지는 방식을 의미한다. 클라이언트는 서버가 수행해야 할 동작을 지정하여 요청(request)한다.

 

▶ HTTP Method 종류

• GET: 데이터를 조회(요청)할 때 사용한다.
• POST: 데이터를 생성, 추가할 때 사용한다.
• PUT: 데이터를 생성, 업데이트할 때 사용한다. (데이터를 완전히 대체한다.)
• PATCH: 데이터 일부분을 수정할 때 사용한다.
• DELETE: 데이터를 삭제할 때 사용한다.
• HEAD: 리소스의 헤더 정보만 요청할 때 사용한다. GET과 유사하지만, 응답 본문을 포함하지 않는다.
• OPTIONS: 리소스가 지원하는 HTTP Method의 목록을 요청할 때 사용한다.
• TRACE: 클라이언트가 서버에 보낸 요청을 그대로 반환받을 때 사용한다. 주로 테스트나 진단 용도로 사용한다.
• CONNECT: 프록시 서버와의 터널 접속을 설정할 때 사용한다. 주로 SSL(HTTPS) 연결을 위해 사용한다.

 

 

✅ HTTP Method의 멱등성에 대해 설명해 주세요.

• 멱등성(idempotence)이란 여러 번 수행해도 결과가 같은 것을 의미한다.
• HTTP Method의 멱등성은 동일한 요청을 여러 번 수행해도 서버의 결과에 영향을 미치지 않는 것을 의미한다. 즉, 여러 번 반복해도 같은 결과를 가져온다는 것이다.

 

▶ HTTP Method의 멱등성

HTTP Method	멱등성	이유
GET	O	같은 요청을 여러 번 해도 같은 결과가 조회된다.
POST	X	같은 요청을 여러 번 하면 새로운 리소스가 생성되거나 리소스의 상태가 달라져 결과가 달라질 수 있다.
PUT	O	같은 요청을 여러 번 해도 저장되는 리소스가 동일하다. (데이터를 완전히 대체하기 때문)
PATCH	X	같은 요청을 여러 번 하면 일부 데이터가 계속 수정 및 추가될 수 있어 결과가 달라질 수 있다.
DELETE	O	같은 요청을 여러 번 해도 삭제된 리소스는 더 이상 존재하지 않으므로 결과가 동일하다.

 

▶ PATCH가 멱등하지 않은 이유

• PATCH는 값을 변경하고자 할 때 주로 사용된다. 이 경우 요청을 여러 번 해도 항상 동일한 결과를 응답받게 된다.
• 그래서 PATCH가 멱등하다고 착각할 수 있는데, 값을 추가(append)하는 요청에도 PATCH가 사용된다. 이 경우 요청을 여러 번 하면 결과가 달라지게 된다.

 

▶ DELETE가 멱등한 이유

• DELETE를 사용하면 클라이언트가 받는 응답 상태 코드가 달라질 수 있음에도 불구하고 DELETE는 멱등하다.
• 왜냐하면 멱등성의 기준이 상태 코드가 아니기 때문이다.
• DELETE의 목적은 리소스를 삭제하여 서버에 리소스가 없도록 만드는 것이고, DELETE를 여러 번 호출해도 응답 상태와 무관하게 리소스가 없는 상태를 유지하도록 한다.
• 멱등성은 리소스 관점에서 생각하는 것이 중요하다.

 

▶ HTTP Method의 멱등성이 필요한 이유

• HTTP Method의 멱등성이 필요한 이유는 요청의 재시도 때문이다.
  • 만약 HTTP 요청이 멱등하다면, 요청이 실패한 경우에도 재시도 요청을 하면 된다. 하지만 만약 HTTP 요청이 멱등하지 않다면, 리소스가 이미 처리되었는데 중복 요청을 보내는 것이 가능해진다.
  • 예: 이미 결제된 요청인데, 중간에 연결이 끊겨서 재결제 요청을 보내면 결제가 두 번 되는 문제가 발생할 수 있다.

 

 

✅ GET과 POST의 차이는 무엇인가요?

	GET	POST
목적	서버에서 데이터를 조회하기 위해 사용한다. 서버의 데이터를 읽거나 검색하는 요청에 적합하다.	서버에 데이터를 전송하거나 리소스를 생성 및 업데이트하기 위해 사용한다. 폼 데이터 전송이나 파일 업로드 등에 적합하다.
데이터 전송 방식	요청 URL의 쿼리 문자열에 데이터를 포함한다. (예: http://example.com/search?query=hello)	요청 본문(body)에 데이터를 포함한다.
캐싱	브라우저나 프록시 서버는 GET 요청에 대한 응답을 캐시한다.	POST 요청은 서버로 전달되어 처리되기 때문에 일반적으로 캐시되지 않는다.
속도	캐싱을 사용하기 때문에 비교적 빠르다.	캐싱을 사용하지 않기 때문에 비교적 느리다.
데이터 길이	URL의 길이 제한으로 인해 전송할 수 있는 데이터의 양이 제한된다.	본문에 데이터를 포함하므로 전송할 수 있는 데이터의 양의 제한이 거의 없다.
멱등성	O	X
보안	URL에 포함된 데이터가 노출되기 쉽다.	본문에 데이터를 포함하므로 URL을 통해 노출되진 않지만, 그래도 HTTPS를 사용하여 데이터 전송을 암호화하는 것이 좋다.
성공 시 상태 코드	200(OK)	201(Created)
북마크 가능성	URL에 모든 데이터를 포함하므로 북마크로 저장하거나 공유하기 쉽다.	URL에 데이터를 포함하지 않으므로 북마크로 저장하거나 공유하기 어렵다.

 

▶ 요약

	GET	POST
목적	데이터 조회	데이터 전송 및 리소스 생성/업데이트
데이터 전송 방식	URL의 쿼리 문자열	요청 본문(body)
캐싱	가능	일반적으로 불가능
속도	비교적 빠름	비교적 느림
데이터 길이	제한 있음 (URL 길이 제한)	제한 없음
멱등성	O	X
보안	URL에 데이터가 노출될 수 있음	데이터가 본문에 포함되어 노출 위험 적음
성공 시 상태 코드	200	201
북마크 가능성	가능	불가능

 

 

✅ POST와 PUT, PATCH의 차이는 무엇인가요?

POST, PUT, PATCH는 모두 서버에 데이터를 전송하는 데 사용되지만, 그 목적과 동작 방식이 다르다.

• POST
  • 목적: 서버에 데이터를 전송하거나 리소스를 생성하거나 업데이트하기 위해 사용한다.
  • 동작 방식: 서버에 데이터를 전송하여 리소스를 생성한다.
  • 특징:
    • 데이터는 요청 본문(body)에 포함된다.
    • 멱등성이 없다. 같은 요청을 여러 번 보내면 리소스가 중복 생성될 수 있다.
    • 주로 폼 데이터를 제출하거나 파일을 업로드할 때 사용된다.
• PUT
  • 목적: 서버에 리소스를 생성하거나 기존 리소스를 대체하기 위해 사용한다.
  • 동작 방식: 리소스가 존재하지 않으면 새로 생성하고, 존재하면 덮어쓴다.
  • 특징:
    • 데이터는 요청 본문(body)에 포함된다.
    • 멱등성을 가진다. 같은 요청을 여러 번 보내도 결과가 동일하다.
    • 리소스의 전체를 갱신하는 데 사용된다.
• PATCH
  • 목적: 서버에 있는 리소스의 일부를 업데이트하기 위해 사용한다.
  • 동작 방식: 리소스의 일부만 수정한다.
  • 특징:
    • 데이터는 요청 본문(body)에 포함된다.
    • 멱등성이 없다. 같은 요청을 여러 번 보내면 일부 필드의 상태가 여러 번 변경될 수 있다.
    • 리소스의 부분 갱신에 사용된다.

▶ 요약

	POST	PUT	PATCH
목적	리소스 생성	리소스 생성 또는 전체 대체	리소스의 일부 갱신
동작 방식	새 리소스 생성	리소스 완전히 덮어씀	리소스의 일부만 변경
멱등성	X	O	X
데이터 전송 방식	요청 본문에 포함	요청 본문에 포함	요청 본문에 포함
사용 예시	폼 데이터 제출, 파일 업로드	전체 리소스 갱신, 리소스 존재하지 않으면 생성	부분 갱신, 특정 필드만 수정

 

 

✅ HTTP 1.1 이후로, GET에도 Body에 데이터를 실을 수 있게 되었습니다. 그럼에도 불구하고 왜 아직도 이런 방식을 지양하는 것일까요?

• 표준의 모호성 및 호환성 문제
  • 표준의 모호성: 공식 문서에서 GET 요청에 본문을 포함할 수 있는 가능성을 배제하지 않았지만, 본문이 있을 경우 본문의 의미와 처리 방법에 대한 구체적인 지침이 없다. 이는 GET 요청의 본문에 대한 표준적인 동작이 정의되지 않았음을 의미하고, 이후 클라이언트와 서버 간 동작을 일관되도록 보장하지 못한다.
  • 호환성 문제: 여전히 많은 클라이언트, 서버, 프록시 및 라우터 등은 GET 요청의 본문을 포함하는 것을 제대로 지원하지 않는다. 따라서 일부 시스템은 GET 요청에 본문이 포함된 경우 이를 무시하거나 오류를 발생시킬 수 있다.
• 캐싱 및 최적화 문제
  • 캐싱: GET 요청은 캐시가 가능하도록 설계되었다. 하지만 GET 요청에 본문을 포함하면 이를 지원하는 캐시 인프라가 모든 사이트에 갖춰지지 않을 수 있어, 특정 캐시 시스템은 이를 제대로 인식하고 처리하지 못할 수 있다.
  • 최적화: 많은 최적화 시스템은 GET 요청이 본문 없이 작동할 것이라고 가정하고 실행하기 때문에, 본문이 포함된 GET 요청은 이러한 최적화 시스템의 혜택을 받지 못할 수 있다.
• 보안 및 관행 문제
  • 보안: GET 요청의 URL은 브라우저 기록, 로그 파일, 북마크 등에 기록될 수 있어 민감한 데이터를 URL에 포함시키는 것은 보안상 위험하다.
  • 관행: RESTful API 설계 원칙에서는 GET 요청을 읽기 전용으로 사용하고, 데이터를 전송하거나 상태를 변경하는 요청에는 POST, PUT, PATCH 등을 사용하는 것이 일반적인 관행이다. 이러한 설계 원칙은 명확성과 일관성을 유지하기 위해 널리 채택되고 있는데, GET 요청에 본문을 포함하는 것은 이러한 원칙을 어기는 것이므로 개발자 커뮤니티에서 지양된다.

 

 

📍 문제 출처

Tech-Interview / 03-NETWORK.md

 

📍 참고 자료

• [HTTP] HTTP 메소드의 멱등성(Idempotence)과 Delete 메소드가 멱등한 이유
• Http Method 란? (GET, POST, PUT, DELETE)
• [네트워크] HTTP Method