RESTful 방식으로 CANCEL 동작을 모델링하는 방법은 무엇입니까?

Question

우리는 현재 우리의 단일체 (monoliths)에서 소규모 서비스를 다루는 중입니다. 우리 도메인은 발권 시스템과 매우 유사합니다. 우리는 도메인의 취소 프로세스부터 시작하기로 결정했습니다.

취소 서비스에는 티켓의 ID를 가져 오는 간단한 "끝내기"끝 점이 있습니다. 내부적으로, 우리는 id를 검색하고, 그것을 취소하고 저장소의 엔터티 상태를 업데이트하는 것과 관련된 몇 가지 작업을 수행합니다. 상점의 관점에서 취소 된 티켓과 라이브 티켓 간의 유일한 차이점은 몇 가지 속성입니다.

내가 읽은 것으로부터, PATCH는이 경우에 사용되는 올바른 동사 인 것으로 보이며 리소스의 단순한 속성 만 업데이트합니다.

PATCH /api/tickets/{id} 
Payload {isCancelled: true} 

그러나 isCancelled는 엔티티의 실제 속성이 아닙니다. 엔티티의 일부가 아닌 페이로드에서 속성을 전송하는 것이 공정한가요? 아니면이 요청을 모델링하는 다른 형태를 생각해야합니까? 그것이 크기 때문에 전체 엔티티를 페이로드의 일부로 보내고 싶지 않습니다.

새로운 리소스 CancelledTickets를 만들려고했지만 Google 도메인에서는 취소 된 티켓에 대해 GET 할 필요가 없습니다. 따라서 어떤 도움을 크게

덕분에 K

Answer 1

정확히 RESTful way 무엇인지 살펴 보자 을 감상 할 수있다

새로운 자원을 생성 할 필요가 떨어져 있었다. 티켓을 사라지게하려면 isCancelled을 페이로드로 사용하거나 DELETE으로 PATCH 요청을 보내도 상관 없습니다. 여전히 RESTful입니다.

이동은 필요에 따라 다릅니다. 당신이

을 말했듯이 나는 새로운 자원 CancelledTickets을 만들 생각했지만, 우리 영역에서 우리는 취소 된 티켓에 GET 할 필요가 없을 것입니다.

나는 단지 DELETE을 보낼 것입니다. 물리적으로 제거 할 필요는 없습니다. 취소를 취소 할 수 있다면 isCancelled 메커니즘을 구현하십시오. 취향에 관한 질문 일뿐입니다.

Answer 2

리소스의 GET 인터페이스 노출은 의무 사항이 아닙니다.

예

는 취소 요청을 제출

PUT /api/tickets/{id}/actions/cancel 

를 사용한다. 실제로 취소 요청이 하나만 있기 때문에 PUT을 선택합니다.

희망이 있으면 도움이됩니다.