GET 및 POST HTTP 요청 방법의 주요 차이점은 무엇입니까?

목적

• GET은 리소스 표현을 요청합니다. 사양에 따르면 읽기 전용입니다. 클라이언트는 서버 상태 변경을 기대하지 않습니다. RFC 9110에서는 GET 요청으로 본문을 보내는 것은 정의되지 않은 의미를 가지므로 GET이 본문을 전달해서는 안 된다고 명시합니다.
• POST는 대상 리소스에게 해당 리소스의 의미(레코드 생성, 양식 제출, 파일 업로드 등)에 따라 요청 본문에 포함된 데이터를 처리하도록 요청합니다.

데이터는 어디로 가는가

• GET은 URL 쿼리 문자열(? 뒤, key=value&... 형식)에 매개변수를 전달합니다. 이는 주소 표시줄에 표시되고 브라우저 기록 및 서버 로그에 기록되며 실제 URL 길이 제한으로 제한됩니다.
• POST는 요청 본문에 데이터를 전달합니다. 유형은 Content-Type 헤더로 제공됩니다. HTML 양식은 일반적으로 application/x-www-form-urlencoded(기본값) 또는 multipart/form-data(파일용)를 사용합니다. 고정된 프로토콜 수준 크기 제한은 없지만 서버와 프록시는 자체 최대값을 구성합니다(예: Nginx client_max_body_size).

RFC 9110에 따른 속성

• 안전함: GET은 안전합니다(읽기 전용). POST는 그렇지 않습니다.
• 멱등성: 요청을 N 번 생성하는 것이 한 번 생성하는 것과 서버 상태에 동일한 영향을 미치는 경우 요청은 멱등적입니다. GET은 멱등성을 갖습니다. POST는 그렇지 않습니다. 이를 반복하면 두 개의 동일한 주문과 같은 중복이 생성될 수 있습니다. 멱등성은 안전함과 동일하지 않으며(PUT 및 DELETE는 멱등성이지만 안전하지 않음) 응답 본문이 동일하다는 사실에 대해 아무 말도 하지 않습니다.
• 캐시 가능: GET 응답은 기본적으로 캐시 가능합니다. POST 응답은 명시적인 최신 정보와 일치하는 Content-Location 헤더를 포함하는 경우에만 캐시할 수 있습니다. 이는 실제로는 드뭅니다.

실제적인 의미

• 검색 및 탐색을 위해 GET을 사용합니다. 결과를 안전하게 반복하고, 북마크하고, 미리 가져올 수 있으며, GET 페이지를 새로 고치는 것은 해롭지 않습니다.
• 상태 변경 작업과 중요하거나 큰 페이로드 전송에는 POST를 사용합니다. POST 페이지를 새로 고치거나 다시 탐색하면 브라우저의 "양식 다시 제출 확인" 경고가 트리거됩니다.
• 절대 GET을 통해 비밀번호를 보내지 마세요. 비밀번호는 URL, 로그, 기록에 남게 됩니다. 이는 암호화가 아닌 위생입니다. HTTPS는 전송 중인 URL과 본문을 모두 암호화하지만 URL은 계속 기록됩니다.

일반적인 후속 조치

• 안전한 메소드는 GET, HEAD, OPTIONS입니다. 멱등성 메서드는 GET, HEAD, PUT, DELETE입니다. POST도 마찬가지입니다.
• 두 방법 모두 HTML 양식(method 속성)에서 지원됩니다.
• RFC 의미에서 "안전하다"는 것은 데이터 보호가 아니라 상태 변경이 없음을 의미합니다.
• 애플리케이션 수준 POST 멱등성은 종종 멱등성 키를 사용하여 시행됩니다.