HTTP는 요청 본문과 함께합니다
질문
응용 프로그램을위한 새로운 RESTful 웹 서비스를 개발하고 있습니다.
특정 엔티티에서 얻을 때 클라이언트는 엔티티의 내용을 요청할 수 있습니다. 일부 매개 변수 (예 : 목록 정렬)를 추가하려면 쿼리 문자열 에이 매개 변수를 추가 할 수 있습니다.
또는 사람들이 요청 본문에서 이러한 매개 변수를 지정할 수 있도록 원합니다. http / 1.1은 명시 적으로 이것을 금지하는 것처럼 보이지 않습니다.이렇게하면 복잡한 XML 요청을 더 쉽게 지정할 수 있습니다.
내 질문 :
- Is this a good idea altogether?
- Will HTTP clients have issues with using request bodies within a GET request?
https://www.rfc-editor.org/rfc/rfc2616.
답변
Roy Fielding의 댓글은 얻을 수있는 신체를 포함합니다.
네.즉, 모든 HTTP 요청 메시지는 메시지 본문을 포함 할 수 있으므로 해당 메시지를 명심해야합니다.그러나 서버 의미는 신체가 요청에 대한 의미 의미가 없도록 제한됩니다.구문 분석에 대한 요구 사항은 메소드 의미의 요구 사항과 별개입니다. 그래서, 예, 당신은 얻을 수있는 몸을 보낼 수 있으며, 그렇게하지는 않습니다. 이는 사양이 분할 된 경우 (진행중인 작업) 해당 스펙을 다시 지우게 될 HTTP / 1.1의 계층화 된 디자인의 일부입니다. .... 로이
예, 요청 본문을 보낼 수는 있지만 의미가 없어야합니다.서버에서 구문 분석하고 내용을 기반으로 응답을 변경하여 의미를 부여하면 HTTP / 1.1 사양, 4.3 절 에서이 권장 사항을 무시하고 있습니다.
... 요청 방법에 엔티티 본문에 대한 정의 된 의미를 포함하지 않으면 요청을 처리 할 때 메시지 본문을 무시해야합니다.
HTTP / 1.1 사양의 GET 메소드에 대한 설명, 9.3 절 :
GET 메소드는 요청-URI에 의해든지 식별되는 정보 ([...])를 검색하는 것을 의미합니다.
요청 본문이 GET 요청에서 자원 식별의 일부가 아니며 요청 URI만이 아닙니다.
업데이트
"http / 1.1 spec"로 참조되는 rfc2616이 쓸모 없게됩니다.2014 년에는 RFCS 7230-7237로 대체되었습니다.견적 "요청을 처리 할 때 메시지 본문이 무시되어야합니다"라는 메시지가 삭제되었습니다.이제는 메소드가 메시지 본문에 대한 사용을 정의하지 않더라도 "제 2 인용구"의 메소드가 메소드 의미론에 독립적 인 경우에도 "요청 메시지 프레임"은 요청서에 의해 식별되는 정보를 검색하는 방법을 검색합니다.삭제되었습니다.- 코멘트에서
HTTP 1.1 2014 사양에서 :
GET 요청 메시지 내의 페이로드는 정의 된 의미가 없습니다.GET 요청에 페이로드 본문을 보내면 일부 기존 구현이 요청을 거부 할 수 있습니다.
답변
당신이 그것을 할 수있는 동안, HTTP 사양에 의해 명시 적으로 배제되지 않으므로 사람들은 단순히 그런 식으로 일을 기대하지 않기 때문에 단순히 그것을 피하는 것이 좋습니다.HTTP 요청 체인에는 많은 단계가 있으며 "주로"HTTP 사양을 준수하는 동안 웹 브라우저에서 전통적으로 사용되는 것처럼 행동 할 것입니다.(투명한 프록시, 가속기, A / V 툴킷 등의 것들을 생각하고 있습니다)
이것은 견고성 원리의 정신이 거칠게 "당신이 받아 들일 수있는 것과서 자유 주의적이며, 당신이 보내는 것에 보수적 인"좋은 이유없이 사양의 경계를 밀고 싶지는 않습니다.
그러나 좋은 이유가 있으면 그것을 위해 가십시오.
답변
캐싱을 활용하려고 노력하는 경우에는 문제가 발생할 것입니다.프록시는 매개 변수가 응답에 영향을 미치는지 확인하기 위해 본문을 보지 않을 것입니다.
답변
RESTCLIENT 또는 REST CONSOLE도이를 지원하지만 컬이 수행하지 않습니다.
HTTP 사양은 4.3 절에 있습니다
요청 메소드의 사양 (5.1.1 절)이 요청시 엔티티 본문을 보낼 수없는 경우 요청에 메시지 본문을 포함해서는 안됩니다.
섹션 5.1.1은 다양한 방법에 대해 9.x 섹션으로 리디렉션합니다.그들 중 누구도 메시지 본문의 포함을 명시 적으로 금지하지 못했습니다.하지만...
섹션 5.2는 말합니다
인터넷 요청에 의해 식별 된 정확한 자원은 요청 URI와 호스트 헤더 필드를 모두 검사하여 결정됩니다.
9.3 절은 말합니다
GET 메소드는 요청-URI에 의해 어떤 정보 (엔티티 형식)가 식별되는 정보를 검색하는 것을 의미합니다.
GET 요청을 처리 할 때 서버는 요청 URI 및 호스트 헤더 필드를 다른 것으로 검사 할 필요가 없습니다.
요약하면 HTTP 사양은 메시지 본문을 가져 오는 것을 방지하지 못하지만 모든 서버에서 지원하지 않는 경우 나에게 놀라지 않는 충분한 모호성이 있습니다.
답변
Elasticsearch는 신체로 요청을받습니다.이것은 이것이 선호하는 방식으로 보입니다 : Elasticsearch Guide
일부 클라이언트 라이브러리 (Ruby 드라이버와 같은)는 개발 모드에서 STDOUT에 CRY 명령을 기록 할 수 있으며이 구문을 광범위하게 사용하고 있습니다.
답변
몸을 보내거나 게시물을 보내고 포스트를 보내고 포스트를 보내고 (그렇게 나쁘지는 않아, 5 년 전 그 믿음의 한 회원만이있었습니다) - 위에 연결된 그의 의견.
훌륭한 의사 결정이 아니지만 얻을 수있는 신체를 보내는 것은 일부 클라이언트와 일부 서버의 문제점을 예방할 수 있습니다.
게시물을하는 것은 어떤 틀림도가있는 장애물을 가질 수 있습니다.
줄리안 재설리는 지원되지 않을 가능성이 훨씬 덜있는 경우를 제외하고는 우아한 솔루션 일 수있는 "검색"과 같은 비표준 HTTP 헤더를 사용하여 위에 제안했습니다.
위의 각각을 할 수 있고 할 수없는 클라이언트를 나열하는 것이 가장 생산적 일 수 있습니다.
신체와 함께 얻을 수없는 고객 (내가 알고있는 것) :
xmlhttprequest fiddler.
몸에 대한 얻을 수있는 고객 :
대부분의 브라우저
GET에서 본문을 검색 할 수있는 서버 및 라이브러리 :
아파치 PHP.
몸체가 얻을 수있는 서버 (및 프록시) :
~을 자란
출처:https://stackoverflow.com/questions/978061/http-get-with-request-body
최근댓글