큰 입력 데이터가있는 REST 끝점 (GET)

Question

일부 계산을 수행하고 호출자에게 결과를 반환하는 REST 끝점에 개체 목록을 전달해야하는 응용 프로그램을 개발 중입니다.

이 상황을 처리하는 방법에 대한 질문은 철학적 인 질문 일뿐입니다.

거대한 페이로드를 GET 요청에 전달하는 것은 나쁜 생각입니다. 동시에 그것은 POST/PUT 요청이 아니므로 서버의 상태를 수정하지 않습니다.

누구도 전에 직면 했습니까?

Answer 1

이 상황을 처리하는 방법에 대한 질문은 철학적 인 질문 일뿐입니다.

웹의 철학 중 일부는 엔드 포인트 구현 방법을 알 필요가 없다는 것입니다. 즉, 미리 계산 된 응답과 다른 사람에게 리디렉션 된 응답이있는 문서 .

순전히 철학적 관점에서 볼 때 GET이 올바른 대답입니다.

GET은 콘텐츠 본문을 지원하지 않습니다. 이 특정 계산의 결과를 리소스로 표현하는 유일한 방법, 즉 URI로 데이터를 가져 오는 것입니다.

실제적으로 URI 길이에 대한 내용은 arbitrary limits입니다. 따라서 클라이언트 (브라우저/라이브러리)에 따라 문제가 될 수 있습니다.

PUT이 좋을 것입니다. POST보다 우위는 PUT이 멱등수 (idempotent)로되어 있다는 것입니다. PUT을 사용하면 유니폼 인터페이스에서 원하는 메시지 분실 의미를 전달합니다.

불행히도 PUT 사양에서는 대상 리소스의 대체 대상에 페이로드 메시지가 필요합니다. 문서 전송에 관한 내용입니다. 즉, RFC-7231는 당신에게 약간의 흔들 거리는 방을주지 ​​않습니다.

풋 표현 대상 자원과 일치하지

는 원 서버가 어느 표현을 변형 또는 자원 구성을 변경하여이를 일관성 또는 이유를 설명하기에 충분한 정보를 포함하는 적절한 오류 메시지가 응답해야 표현이 적합하지 않습니다.

따라서 계산 결과가 표현의 변형이라고 주장 할 수 있습니다.

이 PUT 사용은 실제로 Jim Webber 회담과 다른 점이 전부는 아닙니다. RESTbucks 데모에서는 PUT 메서드를 통해 시스템에 주문을 작성하여 비즈니스 도메인에서 부작용을 유발하고 이로 인해 해당 주문의 상태를 추적하는 데 사용되는 리소스가 생성됩니다.

이러한 접근 방식에서 제출 된 각 계산에는 고유 한 식별자가 있어야합니다. 당신은 그 계산에 입력을 넣을 것이고 결과를 가지고 201 - Created를 반환 할 것입니다. 이론적으로는 리소스에서 GET을 지원하고, 클라이언트가 계산의 결과를 받았으며 서버에서이를 필요로하지 않는다는 확인 응답으로 리소스에 대한 입력 또는 DELETE를 요구하지 않고 결과를 반환 할 수 있습니다. 더 길게.

- 실제로는 필요하지 않으며 모든 리소스에서 모든 http 메소드를 지원할 필요는 없습니다.

이러한 접근 방식을 사용할 수없는 경우 (예 : 미디어 유형으로 HTML을 사용하는 경우) POST는 사용자의 마술 잡기 방식입니다. 실제로 원하는 것에 적합하지 않습니다. POST는 멱등수가 아닌 연산을 지원해야합니다. 즉, 균일 인터페이스가 계산이 멱등수임을 인식하지 못합니다. 행복한 길은 큰 문제가 아닙니다.