긴 실행 시간으로 REST 요청에 접근 하시겠습니까?

Question

우리는 실행하는데 약 5 분이 걸리는 REST 서비스를 구축 중입니다. 그것은 내부 애플 리케이션에 의해 하루에 몇 번만 호출됩니다. 완료하는 데 5 분이 걸리는 REST (즉 : HTTP) 요청을 사용하는 데 문제가 있습니까?

타임 아웃에 대해 걱정해야합니까? 서버의 별도 스레드에서 요청을 시작하고 클라이언트가 상태를 폴링하도록해야합니까?

Answer 1

선택한 프레임 워크를 사용하여 HTTP 시간 초과를 구성 할 수 있다고 가정하면 GET을 통해 요청하고 5 분 동안 정지 할 수 있습니다.

그러나 POST를 통해 실행을 시작하고 영수증 (숫자/ID는 무엇이든)을 얻은 다음 해당 5 분을 사용하여 GET을 수행하는 것이 더 융통성이 있습니다 (그리고 아마도 귀하의 절차는 매 5 분마다 정확히 걸림). 요청이 진행중인 경우 적절한 HTTP 오류 코드 (아마도 404가 아닌 영수증이없는 영수증과 함께 GET으로 반환하겠습니까?)를 반환하거나 가능한 경우 결과를 반환하십시오.

Answer 2

양쪽 끝을 모두 제어하면이면 원하는대로 할 수 있습니다. 예 : 브라우저는 "연결 닫기"헤더를 사용하여 HTTP 요청을 시작하는 경향이 있으므로 적은 옵션으로 남겨 둡니다 .-)

NAT/방화벽을 사이에두고 있으면 드롭 연결이있을 수 있습니다. 얼마 동안 비활성.

"콜백"절차 등록을 제안 할 수 있습니까? 클라이언트는 "callback end-point"와 함께 요청을 발행하여 "ticket"을 얻습니다. 서버가 완료되면 클라이언트를 "콜백 (callback)"하거나 클라이언트가 티켓 식별자를 통해 요청의 상태를 확인할 수 있습니다.

Answer 3

이것은 하나의 접근 방법입니다. 당신이 요청의 현재 상태를보고 싶다면

는 ProcessXYZ

POST /ProcessXYZRequests 

201-Created 
Location: /ProcessXYZRequest/987 

을 수행하는 새로운 요청을 만듭니다

GET /ProcessXYZRequest/987 

<ProcessXYZRequest Id="987"> 
    <Status>In progress</Status> 
    <Cancel method="DELETE" href="/ProcessXYZRequest/987"/> 
</ProcessXYZRequest> 

요청이 완료되면 당신은 볼 것이 뭔가

같은

GET /ProcessXYZRequest/987 

<ProcessXYZRequest> 
    <Status>Completed</Status> 
    <Results href="/ProcessXYZRequest/Results"/> 
</ProcessXYZRequest> 

이 방법을 사용하면 다음 요청이 무엇인지 쉽게 상상할 수 있습니다. 하나는 시간 제한 설정을 제어 할 수 있다면 브라이언 애그뉴가 지적 하듯이, 5 분

GET /ProcessXYZRequests/Pending 
GET /ProcessXYZRequests/Completed 
GET /ProcessXYZRequests/Failed 
GET /ProcessXYZRequests/Today 

Answer 4

을 제공 울드 것은, 자원의 경우 다소 낭비 완전히 관리 할 수 ​​있습니다. 그렇지 않은 경우 결과를 폴링하기 위해 첫 번째로 결과 생성 프로세스를 롤아웃하고 두 번째 (세 번째, 네 번째, 등, 결과가 컴파일 예상보다 오래 걸리는 경우) 두 개 이상의 요청을해야합니다. .

Brian Agnew와 Darrel Miller는 두 가지 (+) 단계 접근법에 대해 비슷한 접근법을 제안합니다. POST는 공장 종점으로 요청하고 서버에서 작업을 시작한 다음 나중에 반환 된 결과 종점에서 결과를 얻습니다.

위의 내용은 매우 일반적인 해결책이며 실제로 REST 제약 조건의 문자를 따르는 반면 RPC는 매우 많이 냄새가납니다.즉, " 리소스"이라는 표현을 제공하는 대신 "이 작업"(RPC)을 실행 한 다음 "작업 실행 결과 인 리소스 표현"을 제공합니다. (휴식). 편집 : 나는 여기 아주 느슨하게 말하고있다. 분명히하기 위해 은 REST 제약을 명시 적으로 무시하지 않지만 REST의 의류에서 비 RESTful 접근법을 드레싱하는 것과 매우 흡사하여 그 과정에서 이점 (예 : 캐싱, idempotency)을 잃었습니다.

이와 같이 클라이언트가 리소스를 먼저 얻으려고하면 서버는 202 "Accepted"(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3)로 응답해야하며 응답 엔터티 어딘가에 "5 분 후에 다시 시도하십시오"라고 대답해야합니다. 그런 다음 클라이언트는 같은 엔드 포인트을 폴링하여 결과를 얻습니다 (그렇지 않으면 다른 202를 리턴하고 나중에 다시 시도하십시오).

이 접근법의 몇 가지 추가 이점은 일회용 리소스 (예 : 작업)가 불필요하게 생성되지 않고 두 개의 개별 끝점을 쿼리 할 필요가 없으며 (출고시 결과) 마찬가지로 두 번째 끝점도 구문 분석에서 결정할 필요가 없다는 것입니다 첫 번째 응답, 따라서 간단합니다. 또한 결과는 "무료"로 (코드별로) 캐시 할 수 있습니다. 문제가 발생한 도메인에 대해 결과가 "유효한"기간에 따라 결과 헤더에 캐시 만료 시간을 설정하십시오.

"리소스 지향"접근 방식의 교과서 예제라고 할 수 있지만 "역설적 웹 서비스"의 8 장에서는 아이러니하게도 2 종점, 공장 접근 방식을 제안합니다. 그림을 이동.