[rest] URL 쿼리 매개 변수가 포함 된 HTTP POST-좋은 아이디어입니까? [닫은]

모든 것이 옳습니다 : 비등 전성 요청에 POST를 사용하십시오.

URI 쿼리 문자열과 요청 내용을 모두 사용하는 것은 어떻습니까? 글쎄, 그것은 유효한 HTTP입니다 (주 1 참조), 왜 그렇지 않습니까?!

쿼리 문자열 부분을 포함한 URL은 리소스 를 찾기 위한 것입니다. HTTP 메소드 동사 (POST-및 선택적 요청 컨텐츠)는 조치 또는 자원 으로 수행 할 작업을 지정하기위한 것입니다 . 그것들은 직교 관심사 여야합니다. 그러나 ContentType = application / x-www-form-urlencoded의 특수한 경우에 대해서는 직교적인 문제가 아닙니다. 아래 참고 2를 참조하십시오.

참고 1 : HTTP 사양 (1.1)에는 쿼리 매개 변수와 내용이 POST 또는 PUT 요청을 수락하는 HTTP 서버에 대해 상호 배타적이라고 명시되어 있지 않습니다. 따라서 모든 서버는 두 가지를 모두 수용 할 수 있습니다. 즉, 서버를 작성하면 융통성이없는 프레임 워크를 제외하고 두 가지를 모두 선택하도록 막을 수있는 것이 없습니다. 일반적으로 서버는 원하는 규칙에 따라 쿼리 문자열을 해석 할 수 있습니다. Content-Type과 같은 다른 헤더를 참조하는 조건부 논리로 해석 할 수도 있습니다.

참고 2 : 경우 웹 브라우저는 사람들이 웹 응용 프로그램에 액세스하는 기본 방법이며, 응용 프로그램 / x-www-form-urlencoded를이 는 IS 당신은 그들이 게시하는 콘텐츠를 입력 해야 하는 콘텐츠 형식에 대한 규칙을 따릅니다. 그리고 application / x-www-form-urlencoded에 대한 규칙은 훨씬 더 구체적이고 솔직한 경우도 있습니다.이 경우 URI를 리소스 위치가 아닌 매개 변수 집합으로 해석해야합니다. [이것은 파워로드가 제기 한 것과 같은 유용성의 지점이다. 웹 양식을 사용하여 서버에 컨텐츠를 게시하는 것이 어려울 수 있습니다. 조금 다르게 설명했습니다.]

참고 3 : 쿼리 문자열은 원래 무엇입니까? RFC 3986은 HTTP 쿼리 문자열을 자원을 찾는 비 계층 적 방식으로 작동하는 URI 부분으로 정의합니다.

이 질문을하는 독자들이 좋은 RESTful 아키텍처가 무엇인지 묻고 자하는 경우 RESTful 아키텍처 패턴은 URI 방식이 특정 방식으로 작동하지 않아도됩니다. RESTful 아키텍처는 리소스의 캐시 가능성, 리소스 자체의 디자인 (동작, 기능 및 표현), dem 등원 충족 여부와 같은 시스템의 다른 속성과 관련이 있습니다. 즉, HTTP 프로토콜 및 HTTP 메소드 동사 세트와 매우 호환되는 디자인을 달성하십시오. 🙂 (즉, RESTful 아키텍처는 리소스의 위치를 잘 예측하지 못합니다 .)

마지막 참고 사항 : 때로는 쿼리 매개 변수가 리소스를 찾거나 콘텐츠를 인코딩하지 않는 다른 용도로 사용됩니다. ‘PUT = true’또는 ‘POST = true’와 같은 쿼리 매개 변수를 본 적이 있습니까? PUT 및 POST 방법을 사용할 수없는 브라우저에 대한 해결 방법입니다. 이러한 매개 변수는 URL 쿼리 문자열 (전선)의 일부로 볼 수 있지만 정신적으로 URL 쿼리의 일부가 아니라고 주장합니다 .

답변