표현이 느리게 생성 된 리소스 집합이 있습니다. 이러한 표현을 구성하는 계산은 서버 부하, 특정 리소스 및 달의 위상에 따라 몇 밀리 초에서 몇 시간까지 걸릴 수 있습니다.
리소스에 대해 수신 된 첫 번째 GET 요청은 서버에서 계산을 시작합니다. 계산이 몇 초 내에 완료되면 계산 된 표현이 반환됩니다. 그렇지 않으면 202 “Accepted”상태 코드가 반환되고 클라이언트는 최종 표현을 사용할 수있을 때까지 리소스를 폴링해야합니다.
이 동작의 이유는 다음과 같습니다. 결과가 몇 초 내에 사용 가능하면 가능한 한 빨리 검색해야합니다. 그렇지 않으면 언제 사용할 수 있는지는 중요하지 않습니다.
제한된 메모리와 엄청난 양의 요청으로 인해 NIO 나 긴 폴링은 옵션 이 아닙니다. 즉 , 거의 충분한 연결을 열어 둘 수 없으며 모든 요청을 메모리에 넣을 수도 없습니다. 한 번 “몇 초” 통과되면 초과 요청을 지속합니다). 마찬가지로 클라이언트 제한으로 인해 완료 콜백을 대신 처리 할 수 없습니다. 마지막으로, 하나가 POST를 수행하는 “공장”리소스를 만드는 데 관심이 없습니다. 추가 왕복은 우리가 원하는 것보다 더 많이 조각 별 실시간 제약 조건을 실패한다는 것을 의미하기 때문입니다. 캐싱의 이점).
GET 요청에 대한 응답으로 202 “Accepted”상태 코드를 반환하는 것에 대해 논란이 있다고 생각합니다. 실제로는 본 적이 없으며 가장 직관적 인 사용은 안전하지 않은 메서드에 대한 응답이지만 특별히 낙담시키는 것을 발견했습니다. 또한 나는 안전과 멱 등성을 모두 보존하고 있지 않습니까?
그렇다면 사람들은이 접근 방식에 대해 어떻게 생각합니까?
편집 : 나는 이것이 브라우저가 아니라 소위 비즈니스 웹 API에 대한 것이라고 언급해야합니다.
답변
잘 정의되고 문서화 된 API에 대한 것이라면 무슨 일이 일어나고 있는지 정확하게202 들립니다 .
공용 인터넷의 경우 클라이언트 호환성이 너무 걱정됩니다. 나는 너무 많은 if (status == 200)하드 코딩 된 것을 보았다 ….이 경우 나는 200.
또한 RFC 는 GET 요청에 202를 사용하는 것이 잘못되었다는 표시를하지 않고 다른 코드 설명 (예 : 200)에서 명확하게 구분합니다.
처리를 위해 요청이 수락되었지만 처리가 완료되지 않았습니다.
답변
우리는 최근 애플리케이션에 대해 이렇게했습니다. 클라이언트 (브라우저가 아닌 사용자 정의 애플리케이션)는 쿼리를 POST하고 서버는 게시되는 “작업”에 대한 URI와 함께 202를 반환합니다. 클라이언트는 해당 URI를 사용하여 결과-이것은 수행중인 작업에 잘 맞는 것 같습니다.
여기서 가장 중요한 것은 서비스 / API의 작동 방식과 202의 응답이 의미하는 바를 문서화하는 것입니다.
답변
내가 기억할 수있는 것에서-GET은 서버를 수정하지 않고 리소스를 반환해야합니다. 활동이 기록되거나 무엇을 가지고 있을지 모르지만 동일한 결과로 요청을 다시 실행할 수 있어야합니다.
반면에 POST는 서버의 상태를 변경하라는 요청입니다. 레코드를 삽입하고, 레코드를 삭제하고, 작업을 실행합니다. 202는 반환되었지만 완료되지 않은 POST에 적합하지만 실제로 GET 요청은 아닙니다.
그것은 모두 매우 청교적이고 야생에서 잘 수행되지 않았으므로 202를 반환하면 안전 할 것입니다. GET은 200을 반환해야합니다. POST는 완료되면 200을 반환하고 완료되지 않은 경우 202를 반환 할 수 있습니다.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
답변
ID (질문에 설명 된 “공장”리소스와 반대)로 명확하게 지정된 엔티티를 표현해야하는 리소스의 경우 GET 메서드를 사용하는 것이 좋습니다. 지연 생성 또는 기타 일시적인 상황으로 인해 엔티티 / 표현을 사용할 수없는 상황에서는 더 적절하고 실제로 이와 같은 상황에 맞게 설계된 503 Service Unavailable 응답 코드를 사용합니다.
이에 대한 이유는 HTTP 자체에 대한 RFC (503 응답 코드에 대한 설명을 확인하십시오) 및 기타 여러 리소스에서 찾을 수 있습니다.
일시적으로 사용할 수없는 페이지에 대해서는 HTTP 상태 코드 와 비교하십시오 . 이 질문은 다른 사용 사례에 관한 것이지만 실제로는 HTTP의 똑같은 기능과 관련이 있습니다.
답변
