"정지 처리"에 대한 HTTP 상태 코드

최종 처리를 위해 장기 실행 작업 큐를 지원하는 RESTful API를 작성 중입니다.

이 API의 일반적인 워크 플로우는 다음과 같습니다.

1. 사용자가 양식을 채 웁니다
2. 고객이 데이터를 API에 게시
3. API가 202를 반환 함
4. 고객이 해당 요청에 대한 고유 URL로 사용자를 리디렉션합니다 ( /results/{request_id})
5. ~ 결국 ~
6. 클라이언트는 URL을 다시 방문하여 해당 페이지의 결과를 봅니다.

문제는 6 단계에 있습니다. 사용자가 페이지를 방문 할 때마다 API ( GET /api/results/{request_id})에 요청을 제출합니다 . 이상적으로는 지금까지 작업이 완료되었으며 작업 결과와 함께 200 OK를 반환합니다.

그러나 사용자는 빠르며 결과 처리가 아직 완료되지 않은 경우 많은 과장된 새로 고침을 기대합니다.

상태 코드가 다음을 나타내는 최선의 옵션은 무엇입니까?

• 이 요청이 존재합니다
• 아직 끝나지 않았습니다.
• 그러나 그것은 또한 실패하지 않았습니다.

단일 코드가 그 모든 것을 전달할 것으로 기대하지는 않지만 클라이언트가 콘텐츠를 기대하게하는 대신 메타 데이터를 전달할 수있는 무언가를 원합니다.

202를 반환하는 것이 합리적 일 수 있습니다. 왜냐하면 여기에는 다른 의미가 없기 때문입니다. GET요청이므로 "허용되는 것"은 없습니다. 이것이 합리적인 선택일까요?

이 모든 기능에 대한 확실한 대안은 작동하지만 상태 코드의 한 가지 목적을 상실하는 경우 항상 메타 데이터를 포함하는 것입니다.

200 OK

{
    status: "complete",
    data: {
        foo: "123"
    }
}

...또는...

200 OK

{
    status: "pending"
}

그런 다음 클라이언트 측, 나는 (한숨) 것 switch에 response.data.status요청이 완료되었는지 여부를 결정합니다.

이것이 내가해야 할 일입니까? 아니면 더 나은 대안이 있습니까? 이것은 나에게 웹 1.0을 느낀다.

HTTP 202 허용 (HTTP / 1.1)

당신은 HTTP 202 Accepted상태를 찾고 있습니다. RFC 2616 참조 :

처리 요청이 승인되었지만 처리가 완료되지 않았습니다.

HTTP 102 처리 (WebDAV)

RFC 2518 은 다음을 사용하도록 제안합니다 HTTP 102 Processing.

102 (처리 중) 상태 코드는 서버가 완료 요청을 수락했지만 아직 완료하지 않았 음을 클라이언트에 알리는 데 사용되는 임시 응답입니다.

그러나주의 사항이 있습니다.

요청이 완료된 후 서버는 반드시 최종 응답을 보내야합니다.

마지막 문장을 해석하는 방법을 잘 모르겠습니다. 서버가 처리하는 동안 아무것도 보내지 않아야 하고 완료 후에 만 응답해야 합니까? 아니면 처리 가 끝날 때만 응답을 강제 종료합니까? 진행 상황을보고하려는 경우 유용 할 수 있습니다. HTTP 102를 보내고 바이트 단위로 (또는 라인 단위로) 응답을 플러시합니다.

예를 들어 길지만 선형적인 프로세스의 경우 각 문자 다음에 플러시하여 100 개의 점을 보낼 수 있습니다. 클라이언트 측 (예 : JavaScript 응용 프로그램)이 정확히 100자를 예상해야한다는 것을 알고 있으면 진행률 표시 줄과 일치시켜 사용자에게 표시 할 수 있습니다.

다른 예는 여러 비선형 단계로 구성된 프로세스와 관련이 있습니다. 각 단계 후에 최종 사용자가 프로세스 진행 상황을 알 수 있도록 사용자에게 표시되는 로그 메시지를 플러시 할 수 있습니다.

점진적 플러싱 문제

이 기술에는 장점 이 있지만 권장하지는 않습니다 . 그 이유 중 하나는 연결을 강제로 열어 두어야하기 때문에 서비스 가용성 측면에서 문제가 생길 수 있으며 확장이 잘되지 않기 때문입니다.

더 나은 접근 방식은 응답을 처리 HTTP 202 Accepted하고 나중에 사용자에게 다시 돌아와서 처리가 종료되었는지 여부를 결정하도록 /process/result하는 것입니다 ( 예 : 프로세스까지 HTTP 404 Not Found 또는 HTTP 409 충돌로 응답 하는 지정된 URI를 반복해서 호출하여) 메시지 큐 서비스 ( 예 :) 또는 WebSocket을 통해 클라이언트를 다시 호출 할 수있는 경우 처리가 완료되면 사용자에게 알리거나 처리가 완료된 경우 사용자에게 알립니다 .

실제 예

비디오를 변환하는 웹 서비스를 상상해보십시오. 진입 점은 다음과 같습니다.

POST /video/convert

HTTP 요청에서 비디오 파일을 가져 와서 마술을합니다. 마술은 CPU를 많이 사용하므로 요청을 전송하는 동안 실시간으로 수행 할 수 없다고 가정 해 봅시다. 즉, 파일이 전송되면 서버는 HTTP 202 AcceptedJSON 콘텐츠로 응답 합니다. "예, 비디오를 받았으며 작업 중입니다. 향후 어딘가에 준비 될 것이며 ID 123을 통해 이용 가능할 것입니다.”

클라이언트는 처리가 완료되면 알림을 받기 위해 메시지 큐를 구독 할 수 있습니다. 완료되면 클라이언트는 다음으로 이동하여 처리 된 비디오를 다운로드 할 수 있습니다.

GET /video/download/123

이는 리드 HTTP 200.

클라이언트가 알림을 받기 전에이 URI를 쿼리하면 어떻게됩니까? HTTP 404실제로 서버는 비디오가 존재하지 않기 때문에 서버가 응답 합니다. 현재 준비 중일 수 있습니다. 요청되지 않았을 수 있습니다. 과거에는 일정 시간이 지난 후 나중에 제거 될 수 있습니다. 중요한 것은 결과 비디오를 사용할 수 없다는 것입니다.

이제 클라이언트가 최종 비디오뿐만 아니라 진행 상황 (메시지 대기열 서비스 또는 이와 유사한 메커니즘이없는 경우 더 중요)에 관심이 있다면 어떻게해야합니까?

이 경우 다른 엔드 포인트를 사용할 수 있습니다.

GET /video/status/123

다음과 비슷한 응답이 발생합니다.

HTTP 200
{
    "id": 123,
    "status": "queued",
    "priority": 2,
    "progress-percent": 0,
    "submitted-utc-time": "2016-04-19T13:59:22"
}

계속해서 요청하면 다음과 같은 진행 상황이 표시됩니다.

HTTP 200
{
    "id": 123,
    "status": "done",
    "progress-percent": 100,
    "submitted-utc-time": "2016-04-19T13:59:22"
}

이러한 세 가지 유형의 요청간에 차이를 만드는 것이 중요합니다.

• POST /video/convert작업을 대기열에 넣습니다. 한 번만 호출해야합니다. 다시 호출하면 추가 작업이 대기됩니다.
• GET /video/download/123작업 결과 와 관련이 있습니다 . 리소스 는 비디오입니다. 요청 이전에 요청과 독립적으로 실제 결과 를 준비 하기 위해 처리 과정에서 발생했던 처리 는 여기와 관련이 없습니다. 한 번 또는 여러 번 호출 할 수 있습니다.
• GET /video/status/123처리 자체에 관한 것이다 . 아무것도 큐에 넣지 않습니다. 결과 비디오에 대해서는 신경 쓰지 않습니다. 리소스 처리 자체이다. 한 번 또는 여러 번 호출 할 수 있습니다.

이 모든 기능에 대한 확실한 대안은 작동하지만 상태 코드의 한 가지 목적을 상실하는 경우 항상 메타 데이터를 포함하는 것입니다.

이것이 올바른 길입니다. 자원이 도메인 특정 로그 (일명 비즈니스 로직)와 관련이있는 상태는 자원 표현의 컨텐츠 유형에 대한 문제입니다.

실제로 다른 두 가지 차이점 개념이 여기에 있습니다. 하나는 자원의 클라이언트와 서버 사이의 상태 전송 상태이고, 다른 하나는 비즈니스 도메인이 해당 자원의 다른 상태를 이해하는 상황에서 자원 자체의 상태입니다. 후자는 HTTP 상태 코드와 관련이 없습니다.

HTTP 상태 코드는 처리되는 리소스의 클라이언트와 서버 간의 상태 전송에 해당하는 리소스의 세부 정보와 독립적으로 일치합니다. 당신 GET이 자원을 당신의 클라이언트가 현재 상태에있는 자원의 표현을 서버에 요구할 때, 그것은 새의 그림 일 수 있고, Word 문서 일 수도 있고, 현재 외부 온도 일 수도 있습니다. HTTP 프로토콜은 중요하지 않습니다. HTTP 상태 코드는 해당 요청의 결과에 해당합니다. DID의 POST서버가 다음 그것을 클라이언트가 볼 수있는 URL을 준 경우 클라이언트에서 서버로 서버에 리소스를 전송? 예? 그렇다면 그것은 201 Created응답입니다.

자원은 현재 '검토 대상'상태 인 항공사 예약일 수 있습니다. 또는 '승인 됨'상태 인 제품 구매 주문일 수 있습니다. 이러한 상태는 도메인에 따라 다르며 HTTP 프로토콜이 아닙니다. HTTP 프로토콜은 클라이언트와 서버 간의 리소스 전송을 처리합니다.

REST와 HTTP의 요점은 프로토콜이 리소스의 세부 사항과 관련이 없다는 것입니다. 이는 도메인 관련 문제와 관련이 없으므로 도메인 관련 문제에 대해 전혀 몰라도 사용할 수 있습니다. 각기 다른 상황 (항공사 예약 시스템, 상상 처리 시스템, 비디오 보안 시스템 등)에서 HTTP 상태 코드의 의미를 해석하지 않습니다.

도메인 특정 항목은 클라이언트와 서버가 Content Type리소스를 기반으로 자신을 파악하는 것 입니다. HTTP 프로토콜은 이것과 무관합니다.

클라이언트가 요청 리소스가 상태를 변경했음을 확인하는 방법에 대해서는 폴링이 클라이언트에서 제어를 유지하고 끊어지지 않은 연결을 가정하지 않기 때문에 최선의 방법입니다. 특히 상태가 바뀔 때까지 몇 시간이 걸리는 경우. REST로 지옥이라고 말하더라도 연결을 열어두고 몇 시간 동안 열어두고 아무것도 잘못되지 않는다고 가정하는 것은 나쁜 생각입니다. 사용자가 클라이언트를 닫거나 네트워크가 종료되면 어떻게됩니까? 세분성이 시간 인 경우 클라이언트는 요청이 '보류 중'에서 '완료'로 변경 될 때까지 몇 분마다 상태를 요청할 수 있습니다.

일을 명확히하는 데 도움이되는 희망

이 블로그의 제안이 합리적이라고 생각했습니다 : REST 및 장기 실행 작업 .

요약:

1. 서버는 클라이언트가 상태를 확인할 수 있도록 "Location"헤더를 URI로 설정하여 코드 "202 Accepted"를 반환합니다 (예 : "/ queue / 12345").
2. 처리가 완료 될 때까지 서버는 "200 OK"및 작업 상태를 표시하는 일부 응답 데이터로 상태 조회에 응답합니다.
3. 처리가 완료된 후 서버는 최종 결과에 대한 URI를 포함하는 "303 See Other"및 "Location"을 사용하여 상태 쿼리에 응답합니다.

리소스에 대한 HTTP 상태 코드를 아직 사용할 수없는 경우 리소스가 생성되는 동안 리소스가 존재하지 않는 경우 404 응답이 아닌 409 충돌 응답을 반환하는 것이 좋습니다.

로부터 W3 사양 :

10.4.10 409 충돌

리소스의 현재 상태와 충돌하여 요청을 완료 할 수 없습니다. 이 코드는 사용자가 충돌을 해결하고 요청을 다시 제출할 수있는 상황에서만 허용됩니다. 응답 본문에는 충분한 내용이 포함되어야합니다

사용자가 충돌의 원인을 인식 할 수있는 정보. 이상적으로, 응답 엔티티는 사용자 또는 사용자 에이전트가 문제를 해결하기에 충분한 정보를 포함 할 것이다. 그러나 불가능할 수도 있고 필요하지 않을 수도 있습니다.

PUT 요청에 대한 응답으로 충돌이 발생할 가능성이 높습니다. 예를 들어, 버전 관리를 사용 중이고 PUT중인 엔티티에 이전 (타사) 요청으로 작성된 자원과 충돌하는 자원에 대한 변경 사항이 포함 된 경우 서버는 409 응답을 사용하여 요청을 완료 할 수 없음을 표시 할 수 있습니다 . 이 경우 응답 엔티티는 응답 Content-Type에 의해 정의 된 형식으로 두 버전 간의 차이점 목록을 포함 할 수 있습니다.

409 코드가 "사용자가 충돌을 해결하고 요청을 다시 제출할 수있는 상황에서만 허용되기 때문에"이것은 약간 어색합니다. 응답 본문에 "이 리소스는 현재 생성 중입니다. [TIME]에 시작되었으며 [TIME]에 완료 될 것으로 예상되는 메시지 (일부 API의 나머지 부분과 일치하는 응답 형식으로 표시)를 포함하는 것이 좋습니다. 나중에 다시 시도하십시오. "

리소스를 요청하는 사용자가 해당 리소스의 생성을 시작한 사용자 일 가능성이 높은 경우에만 409 접근 방식을 제안합니다. 리소스 생성과 관련이없는 사용자는 404 오류가 덜 혼란 스러울 수 있습니다.