HTTP GET 및 POST 의미 및 제한

Question

이번 주 초에 의미 위반이라는 느낌이 들었습니다. 설명하겠습니다.

나는 주어진 수의 매개 변수로 서비스에 요청하는 간단한 AJAX 클라이언트 응용 프로그램을 만들었습니다. 전체 앱은 기본적으로 읽기 전용이므로 HTTP GET을 사용하는 것이 최선의 방법이라고 생각했습니다. 전달해야하는 매개 변수 중 일부는 단순했습니다 (예 : 정렬 순서 또는 페이지 번호).

그러나 필요한 매개 변수 중 하나가 가변 길이 일 수 있으므로 걱정이됩니다. GET 요청의 쿼리 문자열에있는 모든 매개 변수를 인코딩 했으므로 불필요한 upper limit of (roughly) 2000 characters for the request URL을 배치 한 것처럼 보였습니다. 그리고 상관없이 500 자 길이의 요청 URL을 보길 좋아하지 않았습니다.

그래서 POST 요청에는 이와 같은 제한이 없으므로 전환하기로 결정했습니다. 그러나 이것은 옳다고 생각하지 않습니다. POST가 데이터 수정을 의미한다는 인상하에 있지만 간단한 읽기 전용 요청에 사용하고 있습니다.

더 좋은 방법이 있나요? 많은 매개 변수를 사용하여 GET을 수행 하시겠습니까? 한 가지 방법을 들었습니다 - 매개 변수의 사전 POST를 수행 한 다음 GET을 수행하십시오. 그러나이 기술은 많은 것을 남겨두고 있습니다.

그러나이 특정 사례를 살펴보면 HTTP 요청 방법의 실제 의미와 제한 사항은 무엇입니까? 그리고 왜 GET은 어떤 종류의 매개 변수 페이로드도 지원하지 않습니까? URL에있는 쿼리 문자열을 사용하면 거의 나에게 해킹처럼 느껴집니다. 이 문제에 대한

Answer 1

몇 가지 포인트 :

• 는 HTTP 사양 (RFC 2616) 요청 매개 변수를 얻을 forbit하지 않는, 그래서 HTTP GET 자체의 의미의 문제가 아니다. 그러나 많은 HTTP 스택 (클라이언트, 서비스 또는 프록시 용)은 HTTP 요청의 본문을 금지합니다. 사용할 수 없다는 사실은 HTTP GET 요청의 의미 론적 문제보다 구현 세부 사항이 많습니다 (
• ). 마찬가지로 URI (또는 쿼리 문자열) 길이의 제한은 RFC에도 지정되어 있지 않습니다. 이것은 나쁜 클라이언트가 서버 리소스를 소비하는 것을 방지하기 위해 여러 HTTP 서버 스택에 의해 구현되는 보안 완화입니다 (예 : IIS/ASP.NET에서 기본 제한은 2k이지만 web.config의 일부 요소를 통해 늘릴 수 있음). 다시 말하지만, 그것은 의미 론적 의미가 아니라 실질적인 문제입니다.
• POST 요청은 REST 철학을 따르는 경우 데이터 수정을 나타내지 만 읽기 전용 작업에 사용되는 HTTP POST 요청의 예가 많이 있습니다. SOAP은 호출중인 작업이 "안전"인지 "수정 중"인지에 관계없이 모든 요청에서 POST를 사용합니다. 따라서 이러한 작업에 POST를 사용할 수도 있습니다. 그러나 REST (및 "표준 HTTP") 사용법에서 벗어나 GET 요청에는 적용 할 수 있지만 POST에는 적용 할 수없는 캐싱과 같은 프로토콜의 일부 기능을 잃게됩니다.
• 두 가지 요청 (결과를 "얻으려면 매개 변수 + 가져 오기"가있는 POST)를 사용하는 예는 과도한 것처럼 보입니다. 앞에서 언급했듯이 POST 요청은 반드시 리소스 수정을 의미하지 않으므로 하나의 요청이 충분할 때 작업에 액세스하기 위해 새로운 "프로토콜"(POST + GET)을 만들 필요가 없습니다.