일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 사이버보안
- I'm Sorry
- 데이터구조
- 머신러닝
- 빅데이터
- 자바스크립트
- 네트워크
- 웹개발
- 데이터분석
- 소프트웨어
- 딥러닝
- 데이터베이스
- 컴퓨터비전
- 버전관리
- 데이터과학
- 코딩
- 프로그래밍
- 네트워크보안
- 프로그래밍언어
- 인공지능
- 보안
- 컴퓨터공학
- 2
- 알고리즘
- 컴퓨터과학
- 자료구조
- 파이썬
- 소프트웨어공학
- 클라우드컴퓨팅
- Yes
- Today
- Total
스택큐힙리스트
요청 본문과 함께하는 HTTP GET 본문
저희 애플리케이션을 위해 새로운 RESTful 웹서비스를 개발 중입니다.
특정 엔티티에 대해 GET 작업을 수행할 때 클라이언트는 엔티티의 내용을 요청할 수 있습니다.
(예를 들어 목록을 정렬하는 등) 추가 매개 변수를 추가하려면 쿼리 문자열에 이러한 매개 변수를 추가할 수 있습니다.
대안적으로, 사용자들이 요청 바디에서 이러한 매개변수를 지정할 수 있도록 하고 싶습니다. HTTP/1.1 은 명시적으로 이것을 금지하지 않습니다. 이렇게 함으로써 더 많은 정보를 지정할 수 있고, 복잡한 XML 요청을 지정하기가 더 쉬워집니다.
내 질문:
이게 전체적으로 좋은 아이디어인가요?
GET 요청에서 요청 본문을 사용하면 HTTP 클라이언트에 문제가 발생할 수 있습니까?
https://www.rfc-editor.org/rfc/rfc2616
답변 1
Roy Fielding's comment about including a body with a GET request.
예, 다시 말해 모든 HTTP 요청 메시지에는 메시지 바디를 포함할 수 있으며, 이를 고려하여 메시지를 구문 분석해야 합니다. 그러나 GET에 대한 서버 의미론은 바디가 있으면 요청에 대한 의미가 없으므로 제한됩니다. 구문 분석에 대한 요구 사항과 메소드 의미론에 대한 요구 사항은 별도로 존재합니다.
그래서 예, GET으로 본문을 보낼 수 있지만, 그렇게 하는 것이 언제나 유용하지는 않습니다.
이것은 HTTP/1.1의 계층적 설계의 일부입니다. 이 명세가 분할되면 다시 명확해질 것입니다 (진행중인 작업입니다).
로이
네, GET으로 요청 본문을 보낼 수 있지만 의미는 없어야 합니다. 서버에서 파싱하고 내용에 따라 응답을 변경하면 이 권장 사항을 무시한 것입니다. the HTTP/1.1 spec, section 4.3:
...만약 요청 메소드가 개체 본문에 대한 정의된 의미를 포함하지 않는다면, 요청을 처리할 때 메시지 본문은 SHOULD 무시될 수 있습니다.
그리고 the HTTP/1.1 spec, section 9.3에서 GET 방법의 설명 :
GET 방법은 요청 URI에 의해 식별된 정보를 검색하는 것을 의미합니다.
GET 요청에서 요청 본문은 리소스 식별의 일부가 아니며, 요청 URI만이 식별의 일부임을 명시합니다.
업데이트
HTTP/1.1 스펙으로 참조된 RFC2616은 이제는 구식입니다. 2014년에 RFCs 7230-7237로 대체되었습니다. 요청 처리시 메시지 본문은 무시되어야 합니다는 인용 부분이 삭제되었습니다. 이제는 요청 메시지 프레임은 메소드 의미론과 독립적이며, 메소드가 메시지 본문에 대한 사용을 정의하지 않더라도입니다. 두 번째 인용구 GET 메소드는 Request-URI에 식별된 정보를 검색한다가 삭제되었습니다. - 댓글에서
HTTP 1.1 2014 Spec에서부터:
GET 요청 메시지 내의 페이로드에는 정의 된 의미가 없습니다. GET 요청에 페이로드 바디를 보내면 일부 기존 구현에서 요청을 거부할 수 있습니다.
답변 2
HTTP GET with Request Body (HTTP GET 요청 본문)
HTTP(GET) 요청은 요청 본문(request body)을 포함하지 않는 것으로 알려져 있다. 하지만, 일부 상황에서는 요청 매개변수 형식으로 전달되는 대형 데이터를(예: JSON 또는 XML)보다 효율적으로 전송하려면 요청 본문을 사용해야 한다.
요청 매개변수로 전달되는 데이터의 양이 매우 크거나, 암호화되어야 하는 데이터 등 요청 본문을 사용해 전송해야 하는 데이터의 형식은 다양하다. 이러한 경우 HTTP POST, PUT 또는 PATCH 요청 메서드를 사용할 수 있지만, 이들 요청 메서드는 서버에서 해당 리소스를 변경 또는 생성하기 때문에 그 의도와 일치하지 않는다.
따라서, 요청 본문(request body)을 포함한 HTTP GET 요청을 보내는 방법이 있다. 이 방법을 사용하면 요청 본문에 대량의 데이터를 포함하고 이를 서버로 전송할 수 있다. 이 방법을 사용하는 경우, 요청 본문에 데이터를 추가하고 URL에는 기본 요청 매개변수를 추가한다.
HTTP(GET) 요청 본문을 사용하면 서버 데이터를 한 번에 검색할 수 있다. 이 방법은 수행 시간을 단축하고 대량의 데이터를 처리하거나 검색할 때 매우 유용하다.
하지만, HTTP GET 요청에서 요청 본문을 사용하는 것은 RESTful API 디자인 원칙에 어긋난다. RESTful API의 디자인 원칙 중 하나는 요청이 서버 상태를 변경하지 않는 것이다. HTTP(GET) 요청 본문은 URI(Uniform Resource Identifier)로 식별되는 리소스를 검색하기 위해 사용되기 때문에 RESTful API의 디자인 원칙에 맞지 않는다.
결론적으로, HTTP(GET) 요청 본문을 사용할 때는 해당 매개변수들이 서버 로그에 보이지 않도록하는 등 보안을 고려해야 한다. 또한, RESTful API 디자인 원칙을 준수하는 것이 중요하다. 하지만, 경우에 따라서는 HTTP(GET) 요청 본문을 사용하는 것이 효과적일 수 있다.