비동기 작업에 http 상태 202 사용

비동기 작업에 http 상태 202 사용

---

사용자 제공 데이터를 수락하는 서비스 용 REST API를 작성 중입니다. 모든 작업을 완전히 비동기 적으로 유지하고 싶습니다. 여기에는 PUT, POST, DELETE 및 GET 요청이 포함됩니다. 내 생각은 요청을 수신하고 유효한 요청인지 확인한 다음 HTTP 202 허용 응답과 함께 데이터를 최종적으로 사용할 수있는 URL 및 토큰을 전달하여 후속 요청을 처리 된 데이터와 일치시킬 수 있도록하는 것입니다. . 요청이 유효하지 않으면 HTTP 400을 보냅니다.

그러면 클라이언트는 나중에 제공 한 URL을 확인하고 토큰을 전달할 책임이 있습니다. 데이터를 사용할 수있는 경우 일반 200 또는 201을 반환하지만 여전히 요청을 처리중인 경우 처리가 완료되지 않았 음을 나타내는 다른 202를 보냅니다. 데이터 처리 오류의 경우 필요에 따라 4xx 또는 5xx 상태를 보냅니다.

이 작업을 수행하려는 이유는 모든 유효한 요청을 요청 풀에 덤프하고 작업자가 대기열에서 가져와 사용 가능한 요청을 처리하도록하기 위해서입니다. 풀 크기 나 사용 가능한 작업자 수를 모르기 때문에 Google App Engine의 30 초 제한을 충족 할만큼 빠르게 요청을받을 수 있는지 확신 할 수 없습니다.

내 질문은 : 이런 방식으로 요청을 처리하여 REST를 왜곡하고 있습니까? 예를 들어 브라우저는 요청에 대한 즉각적인 응답을 요구하는 것 같습니다. 내 HTML 페이지의 경우 구조화 된 페이지로 응답 한 다음 AJAX를 사용하여 데이터 요청을 처리 할 계획입니다.

저는 이러한 방식으로 REST를 사용하여 데이터를 처리하는 데 대한 의견이나 경험에 주로 관심이 있습니다.

---

난 당신 솔루션 괜찮 생각은은 Http status 202은 IS 적절한 응답 을 나타내는이 특정한 경우에 사용하는 요청 처리가 승인되었지만 처리가 완료되지 않았습니다 .

귀하의 워크 플로에서 약간 변경하려는 Http status것은 후속 요청입니다.

말했듯 이은 클라이언트가 이전 요청의 상태를 모니터링하는 데 사용해야하는 URL을 202 response반환 Location header해야합니다.
이 Check-the-status-of-my-process URL을 호출하면 프로세스가 보류중인 경우 202를 반환하는 대신 다음을 반환합니다.

1. 200 OK요청 된 프로세스가 아직 보류 중일 때. 응답은 프로세스의 보류 상태를 설명해야합니다.
2. 201 Created처리가 완료되었을 때. GET / PUT / POST의 경우 응답에는 요청 / 생성 / 업데이트 된 리소스에 대한 위치가 포함되어야합니다.

---

오래된 질문에 내 2 센트를 더합니다. 내 아이디어는 systempuntoout 및 Avi Flax의 제안과 유사합니다.

헤더 HTTP 202를 통해 다른 리소스로 리디렉션하는 초기 요청에 대한 응답이 적절 하다는 데 동의합니다 Location.

LocationURL에는 Location리디렉션의 일반적인 기대치를 준수하기 위해 참조하는 토큰이 포함되어야 한다고 생각합니다 . 예를 들어 Location: /queue?token={unique_token}또는 Location: /task/{unique_token}.

또한 프로세스 상태를 확인하는 데 사용되는 리소스 HTTP 200는 "상태 확인"작업이 성공할 때 응답을 반환해야한다고 생각합니다 ( HTTP 202현재 요청이 "수락 됨"을 의미하기 때문이 아닙니다 ).

그러나 새 엔티티가 생성되면 "상태 확인"이 생성되면 새 엔티티 에 대한 헤더 와 함께 HTTP 303( 기타 참조 ) 응답을 반환해야한다고 Location생각합니다. 상태 확인을 위해 방금 수행 HTTP 201한 GET요청 으로 인해 생성 된 것이 없기 때문에를 보내는 것보다 더 적절 합니다.

또한 상태를 확인하는 데 사용되는 리소스가 오류 코드를 적절하게 반환해야한다고 생각합니다. "상태 확인"이 성공적으로 수행 될 때마다 적절한 성공 코드가 반환되어야합니다. 오류는 응용 프로그램 수준에서 처리 할 수 ​​있습니다 (응답 본문 확인).

---

이것은 정말 오래된 질문입니다. 그러나 저는 이것에 대해 약간 다른 견해를 제시하고 싶습니다. 제가 옳다고 주장하는 것이 아니라 단지 제 견해입니다.

클라이언트 관점에서

초기 HTTP 요청부터 시작하겠습니다. 무엇보다도 요청은 POST 여야합니다. 리소스를 만들기 위해 서버에 메시지를 보내고 있습니다. 이 경우 GET 및 PUT는 다음과 같은 이유로 유효하지 않습니다.

• GET은 특정 위치에서 리소스를 얻기위한 것이기 때문에이 컨텍스트에서 GET은 유효하지 않습니다.
• 요청을 생성하지 않기 때문에 PUT가 유효하지 않습니다. 서버에 요청 생성을 요청하는 것입니다.

서비스 관점에서

이제 요청을 처리하기 위해 서버에 POST를 보내고 있습니다. 서버에는 실제로 3 개의 가능한 반환 값이 있습니다 (4xx 및 5xx 오류 제외).

• "201 Created"는 서비스가 요청을 받았으며 즉시 또는 허용 가능한 기간 내에 처리 할 수 ​​있음을 나타냅니다. 이 기간은 전적으로 서비스 설계에 달려 있습니다. 이를 정의하는 것은 서비스 개발자에게 달려 있습니다.
• "202 Accepted"는 서비스가 요청을 받아 처리 중임을 나타냅니다. 이것은 서비스가 시간이 걸릴 것이라는 것을 알 때 사용됩니다. 다른 관점은 서비스가 결과를 결정할 방법이없는 다른 비동기 작업에 의존하는 경우 "202 Accepted"응답을 반환해야한다는 것입니다. 마지막으로 일부 서비스 디자이너는 얼마나 빨리 수행 할 수 있는지에 관계없이 항상 "202 Accepted"를 반환 할 수 있습니다.
• 어떤 경우에는 "302 Found"가 표시됩니다. 이는 일반적으로 서비스가 이미 존재하는 (그리고 여전히 유효하며 오류 상태가 아닌) 자원을 생성하는 것으로 요청을 식별 할 수 있고 기존 자원을 재사용 할 수있는 경우입니다. 모든 서비스가 다음과 같이 작동하는 것은 아닙니다. 스레드에 댓글을 게시하면 항상 새 리소스가 생성되어야합니다. 기타 서비스 : 의사 목록을 얻기위한 일련의 기준을 게시하면 동일한 의사 목록이 생성됩니다. 이 정보를 재사용 할 수 있으면 재사용하십시오.
• 이러한 모든 응답과 함께 "위치"HTTP 헤더는 리소스를 찾을 수있는 위치를 포함하는 클라이언트로 반환됩니다. 이것은 중요하며 나중에 보게 되겠지만 일부 사람들은 접근 방식이 다른 경향이 있습니다. 리소스를 다른 요청과 함께 재사용 할 수있는 경우 동일한 요청이 항상 동일한 URL을 생성하는 방식으로 "위치"를 생성해야합니다. 이것은 많은 캐싱과 재사용을 제공합니다.

서비스가 요청을 성공적으로 완료하면 클라이언트에 반환 된 위치에 리소스를 생성합니다.

이제 여기에서 위의 응답과 약간 다른 것을 보게됩니다.

서비스가 요청을 완료하지 못하는 경우에도 클라이언트에 반환 된 위치에 리소스를 만들어야합니다. 이 리소스는 실패 이유를 나타내야합니다. 리소스가 실패 정보를 HTTP 프로토콜에 통합하는 것보다 제공하는 것이 훨씬 더 유연합니다.

서비스가 완료되기 전에이 리소스에 대한 요청을 받으면 "404 Not Found"를 반환해야합니다. "404 찾을 수 없음"이어야한다고 생각하는 이유는 실제로 존재하지 않기 때문입니다. HTTP 사양은 "404 찾을 수 없음"은 자원이 존재하지 않을 때만 사용할 수 있다고 말하지 않고 현재 존재하지 않는다는 것입니다. 비동기 폴링 흐름에 대한 이러한 유형의 응답은 제 생각에는 완전히 정확합니다.

There is also the scenario of when a resource is supposed to only be there for a fixed time. For example, it may be data based on a source that is refreshed nightly. What should happen in these cases is that the resource should be removed, but an indicator should be provided to the service that it can know to return a "410 Gone" status code. This basically is telling the client that the resource was here, but is no longer available (ie: may have expired). The typical action from the client would be to resubmit the request.

From the client perspective again

When the client gets the response for it's initial POST, it gets the "Location" and makes the request to the service using that URL using a GET (again, not POST). The service will generally response with these values:

• "200 OK" indicates that the request did complete. The result of the request is returned in the content body, providing the content in the format defined by the Accept HTTP header.
• "404 Not Found" would tell the client that the request did not complete yet, the resource is not there yet, and, in this case, it should basically try again later.
• "410 Gone" would be returned in cases where the client may attempt to get the resource after a long period of time and it's not there anymore. In this case, it should simply resubmit the original query

The one thing that needs to be pointed out is that the resource that is returned is generally in a format that can define success and failure responses. The client should be able to determine from this resource if there was an error, what it was, and be able to respond accordingly.

Also, the service developer may make it so that service expires and deletes the error resource after a short period of time.

So that's my thoughts on this question. It's very late to the party, but hopefully future readers may see a slightly different view to a commonly asked question.

---

FWIW, Microsoft Flow uses a pattern like this.
First call returns 202 w/ Location header. Followup calls return either: 1. If still processing --> 202 w/ a location header. The loc header can be different, which provides a way to pass state between calls (and potentially make the server stateless!). 2. If done --> 200.

Details at: https://github.com/jeffhollan/LogicAppsAsyncResponseSample

ReferenceURL : https://stackoverflow.com/questions/5079367/use-http-status-202-for-asynchronous-operations