HTTP GET 쿼리 문자열 길이 제한을 처리하고 여전히 RESTful을 원합니까?

http://www.boutell.com/newfaq/misc/urllength.html에 명시된 바와 같이 HTTP 쿼리 문자열의 길이는 제한되어 있습니다. 클라이언트 (Firefox, IE, ...), 서버 (Apache, IIS, ...) 또는 네트워크 장비 (적용 방화벽, ...)에 의해 제한 될 수 있습니다.

오늘 저는 검색 양식으로이 문제에 직면합니다. 많은 필드가 포함 된 검색 양식을 개발했으며이 양식은 GET 요청으로 서버에 전송되므로 결과 페이지를 북마크 할 수 있습니다.

쿼리 문자열의 길이가 1100 바이트 인 필드가 너무 많고 1024 바이트가 넘는 HTTP GET 요청을 삭제하는 방화벽이 있습니다. 시스템 관리자는 제한이 없도록 대신 POST를 사용하도록 권장합니다.

물론 POST는 작동하지만 검색은 POST가 아닌 GET으로 느껴집니다. 따라서 쿼리 문자열이 너무 길지 않은지 확인하기 위해 필드 이름을 검토하고, 그렇게 할 수 없으면 실용적으로 POST를 사용할 것입니다.

그러나 RESTful 서비스 설계에 결함이 있습니까? GET 요청의 길이가 제한되어 있다면 어떻게 큰 객체를 RESTful 웹 서비스로 보낼 수 있습니까? 예를 들어, 파일을 기반으로 계산하는 프로그램이 있고 다음과 같은 RESTful 웹 서비스를 제공하려는 경우 : http://compute.com?content=<base64 file>. 쿼리 문자열의 길이에 제한이 없기 때문에 작동하지 않습니다.

조금 당황 스럽네요 ...

설명에 따라 IMHO는 POST를 사용해야합니다. POST는 서버에 데이터를 저장하고 경우에 따라 답변을 얻기위한 것입니다. 귀하의 경우 검색을 수행하고 (서버에 쿼리 보내기) 해당 검색 결과를 가져옵니다 (쿼리 결과 검색).

GET의 정의는 이미 존재하는 자원을 검색하는 데 사용되어야한다고 말합니다. 정의에 따라 POST는 새 리소스를 만드는 것입니다. 이것이 바로 당신이하고있는 일입니다. 서버에 리소스를 생성하고 검색하는 것입니다! 검색 결과를 저장하지 않더라도 서버에 개체를 만들어 검색했습니다. PeterMmm이 미리 말했듯이 POST (쿼리 결과 생성 및 저장)를 사용하여이를 수행 한 다음 GET을 사용하여 쿼리를 검색 할 수 있지만 POST 만 수행하고 결과를 검색하는 것이 더 실용적입니다.

도움이 되었기를 바랍니다! :)

HTTP 사양은 실제로 계산을 위해 데이터를 리소스 로 보낼 때 POST를 사용하도록 권장합니다 .

검색은 리소스 자체가 아니라 계산처럼 보입니다. 검색 결과가 리소스가되기를 원한다면 할 수있는 일은 특정 검색 결과를 식별하는 토큰을 만들고 사용자 에이전트를 해당 리소스로 리디렉션하는 것입니다.

그런 다음 일정 시간 후에 검색 결과 토큰을 삭제할 수 있습니다.

예

POST /search
query=something&category=c1&category=c2&...

201 Created
Location: /search/01543164876

그때

GET /search/01543164876

200 Ok
... your results here...

이렇게하면 브라우저와 프록시가 검색 결과를 계속 캐시 할 수 있지만 POST를 사용하여 쿼리 매개 변수를 제출합니다.

편집하다

명확히하기 위해 01543164876여기는 검색을 나타내는 리소스의 고유 ID를 나타냅니다. 이 두 가지 요청은 기본적으로 이러한 기준으로 새 검색 개체를 만든 다음 생성 된 검색 개체와 관련된 결과를 검색합니다.

이 ID는 각각의 새 요청에 대해 생성 된 고유 ID 일 수 있습니다. 이는 서버가 "검색"개체를 유출하고 캐싱 전략을 사용하여 정기적으로 정리해야 함을 의미합니다.

또는 사용자가 요청한 검색을 실제로 나타내는 모든 검색 기준의 해시 일 수 있습니다. 이렇게하면 검색을 다시 만들면 이미 캐시 된 (또는 그렇지 않을 수있는) 기존 ID가 반환되므로 ID를 재사용 할 수 있습니다.

REST는 프로토콜이 아니라 작업을 수행하는 방식입니다. 실제로 GET 일 때 POST를 싫어하더라도 작동합니다.

쿼리를 POST하는 것보다 GET, POST 등의 "표준"정의를 유지해야하는 경우 해당 쿼리는 쿼리 ID로 서버에 저장되고 나중에 GET by id로 쿼리를 요청합니다.

귀하의 예와 관련하여 : http://compute.com?content={base64file}, 계산할 "무언가"를 업로드하기 때문에 POST를 사용합니다. 나에게이 "무언가"는 단순한 매개 변수로서의 리소스처럼 느껴집니다.

일반적인 검색에서 이와 달리 GET 및 매개 변수를 사용하기 시작합니다. API 클라이언트가 API를 훨씬 쉽게 테스트하고 사용할 수 있습니다. 읽기 전용 액세스 (대부분의 경우 대부분의 트래픽)를 가능한 간단하게 만드십시오!

그러나 큰 쿼리 문자열의 딜레마는 GET의 유효한 제한입니다. 이 제한에 도달하지 않는 한 GET 및 url-params와 함께 사용하면 실용적으로 갈 것입니다. 이는 검색 사례의 98 %에서 작동합니다. 이 제한에 도달 한 경우에만 작동 한 다음 페이로드 (mime-type 사용 Content-Type: application/x-www-form-urlencoded) 와 함께 POST를 도입하십시오 .

실제 사례가 더 있습니까?

GET에 대한 혼란은 브라우저 제한입니다. A2A 또는 P2P 애플리케이션을위한 RESTful 인터페이스를 생성하는 경우 GET 길이에 제한이 없습니다.

이제 브라우저를 사용하여 RESTful 인터페이스 (일명 개발 / 디버깅 중)를 보려면이 제한에 도달하게되지만이를 해결할 수있는 도구가 있습니다.

이것은 쉬운 일입니다. POST를 사용하십시오. HTTP는 GET의 URL 길이에 제한을 두지 않지만 서버는 제한합니다. 실용적으로 행동하고 POST로 해결하십시오.

GET 본문 (허용됨)을 사용할 수도 있지만 올바른 사용법이 아니며 아마도 서버 문제가 발생할 수 있다는 점에서 이중 문제입니다.