가져 오기를 수행 할 때 뭔가를 제거하는 것이 쉽지 않은가요?

Question

자발적으로 대답은 당연히 아니오입니다. 그래서 내가 무엇을 이해하고 있는지 설명해 드리겠습니다.

우리는 클라이언트가 POST 작업이 실행되지만 게시 시점에 실행되지 않는 서비스가 있습니다. 대신 우리의 서비스는 고객이 GET을 통해 job을 실행하는 데 사용할 수있는 ID로 응답합니다.

이제 작업이 실행되면 해당 작업도 제거되고 더 이상 해당 작업을 사용할 수 없습니다.

RESTfull 아키텍처가 무엇인지에 대한 이해에서, 우리 구현은 REST의 아이디어를 따르지 않습니다.

제가 궁금해하는 점은 RESTfull이 아니라면 우리는 어떻게 재 설계해야합니까? 그것은 변화의 문제가 우리의 GET 내 말은 job으로 job

을 실행 한 이후 DELETE도 이상한 것 같다 동시에 (일 (작업)을 제거 할 때부터 난, 믿지 않는) POST에 우리는 우리 DB로부터 아마도 엄청난 양의 데이터를 제공하고 있습니다.

Answer 1

우리 서비스는 클라이언트가 GET을 통해 작업을 실행하는 데 사용할 수있는 ID로 응답합니다.

RESTful 인 것처럼 들립니다. 클라이언트는 execute으로 작업 상태를 설정하여 작업 소스에 PUT을 보내야합니다.

PUT /jobs/1234 
{ 
    "status": "execute" 
} 

200 OK 

클라이언트는 나중에 GET 상태 확인을위한 작업 자원이 될 수 있습니다. 나중에 상태가 completed으로 변경됩니다. 잠시 후 시스템의 일부 다른 부분이 completed 작업을 제거하면

GET /jobs/1234 

200 OK 
{ 
    "id": 1234, 
    "status": "completed", 
    "quizzle": "smooth" 
} 

, 작업 리소스에 GET는 410 Gone 될 것입니다.

GET /jobs/1234 

410 Gone 

Answer 2

아니요. get을 통해 작업을 실행하지 마십시오. 작업이 이미 실행되었고 누군가 POST를 다시 시도하면 작업이 이미 실행되었다는 설명과 함께 422 Unprocessable Entity을 반환하십시오. 정말로 필요한 경우 두 번째 게시물에서 작업을 삭제할 수 있습니다. 클라이언트가 작업을 삭제할시기 /시기를 결정하게하는 것이 좋습니다.

send up a job: 
POST /jobs 
{ .. } 

execute a job: 
POST /executed-jobs 
==> { "jobId": 12345 } 
<== { "expectedCompletionTime": "<timestamp>" } 

Answer 3

RESTfull은 URI를 사용하여 리소스를 표현하고 HTTP 동사를 사용하여 작업하는 주된 개념입니다. 나는 다음과 같은 세 가지 해결책을 제안 할 것이다.

1. 작업의 필드 즉, 실행 대기 중 상태가 변경되어 백엔드에서 신호를 발생시키고 작업을 시작할 수있는 PATCH 요청을 할 수 있습니다. 후속 PATCH 요청은 400 또는 409 응답 코드를 리턴 할 수 있습니다.
2. /jobs/: job_id/execute /로 POST 요청을하면 작업 실행이 시작됩니다. 응답은 위와 같을 수 있습니다.
3. GET 요청에 부작용을 추가 할 수 있습니다 (작업 실행입니다). 처음 상태가 실행될 때 실행 상태로 변경됩니다. 이 도움이

희망, 그것은 좋은 토론 주제 :의

이 질문은