비 CRUD 작업을 처리하기 위해 REST API를 설계하는 방법은 무엇입니까?

SOAP 기반 서비스 세트를 RESTful API로 변환하려고합니다.

작업 이름을 분석하여 리소스를 식별하는 것으로 시작했으며 리소스를 얻었습니다 Subscription.

구독 상태를 업데이트해야 할 때 POST리소스에 직접 액세스 할 수 없기 때문에 서버에 요청을 보낼 수는 없지만 속성을 업데이트하려면 RPC 스타일 작업을 호출해야합니다. 또한 구독 상태를 "active"로 변경하는 경우에만 외부 서비스에 대한 추가 호출이 필요합니다.

이 경우 기본 작업을 처리하는 가장 좋은 방법은 무엇입니까?

내가 찾은 해결책은 쿼리 매개 변수를 사용하는 것이므로 활성화 서비스를 호출 해야하는 경우 다음과 같은 것을 사용할 수 있습니다.

POST /subscriptions/{subscriptionid}/?activate=true

구독 객체 필드를 직접 업데이트 할 수 없다는 것을 고려할 때 이러한 종류의 변환을 처리하는 가장 좋은 방법이 있습니까?

업데이트 1 :

POST 요청의 본문에 "state": "active"와 같은 값을 넣을 수 있습니다.

내 서비스 내부에서 적절한 작업이 트리거되는지 확인하십시오.

— 벡터
소스

복잡한 조작으로 HTTP 동사에 대한 REST의 명령 맵핑이 실패합니다. RPC 스타일 호출을 사용하는 것이 좋습니다. POST activateSubscription / {id} 아무도 혼동하지 않습니다.

— Ewan

@Ewan 나는 이것이 RESTful 모델을 준수하는지 확실하지 않지만 다른 해결책을 생각해 냈습니다. 내 코드에서 입력 페이로드에 따라 적절한 RPC 스타일 작업을 호출 할 수 있습니다 ( 내 게시물 요청, 코드는 활성화 코드를 호출합니다)

— Vektor88

이와 같은 기존 리소스에 대한 업데이트는 PATCH 여야하며 쿼리 본문은 변경하는 내용의 부분 모델입니다. POST는 리소스를 생성하는 요청이어야합니다. 이 구별은 사용자에게 명확하게하는 것 외에도 리소스 게시물이 아니라이 작업이 언제 발생하는지 코드가 쉽게 알 수있게합니다.

— Mr Cochese

@ Vektor88 일반적으로 전체 리소스 상태 표현을 전달해야하는 dem 등식 작업입니다. 이 사용 사례는 부분 업데이트와 훨씬 비슷해 PATCH에 매우 적합합니다.

— Mr Cochese

@MrCochese POST는 dem 등성이 아닙니다.

— JimmyJames

답변:

Jim Webber 의이 연설 을 봐야 합니다 .

구독 상태를 업데이트해야 할 때 리소스에 직접 액세스 할 수 없기 때문에 단순히 POST 요청을 서버에 보낼 수는 없지만 속성을 업데이트하려면 일부 RPC 스타일 작업을 호출해야합니다. 또한 구독 상태를 "active"로 변경하는 경우에만 외부 서비스에 대한 추가 호출이 필요합니다.

"메시지"를 생각하십시오. 원하는 것을 설명하는 메시지를 도메인에 보냅니다. 메시지의 부작용은 도메인 모델이 실제로 상태를 변경한다는 것입니다. "자원"은 메시지 큐입니다.

POST /subscriptions/{subscriptionid}/?activate=true

자원 이름의 철자는 시스템에 중요하지 않습니다. 그러나 사람들이 사용하는 식별자가 리소스가 "명사"라는 관례에서 벗어나면 까다로워지는 경향이 있습니다.

또한 우리는 종속적 인 자원에 대해 이야기하고 /subscriptions/{subscriptionid}있으므로 규칙 ( RFC 3986 참조 )은 쿼리 부분을 사용하는 대신 경로 세그먼트와의 관계를 표현해야합니다.

따라서이 철자가 합리적 일 수 있습니다

POST /subscriptions/{subscriptionid}/messages
POST /subscriptions/{subscriptionid}/activations

— VoiceOfUnreason
소스

Jim Webber의 강연은 youtube.com/watch?v=aQVSzMV8DWc

— user674669

부울 플래그가 물건을 활성화 / 비활성화하는 경우 기본값은 JSON을 사용하는 것입니다.

POST /subscriptions/{subscriptionid}/
{
    format: 0,
    subscription: 
    {
        active: false
    }
}

더 많은 속성을 지원하려는 경우 쉽게 확장 할 수 있습니다. 또 다른 접근법은 자체 엔드 포인트를 제공하는 것입니다.

POST /subscriptions/{subscriptionid}/active/
DELETE /subscriptions/{subscriptionid}/active/

개인적으로, 나는 active이 이벤트 의 상태가 사용자 ID 또는 설정과 같이 JSON으로 전달 / 가져올 수있는 속성이 필요한 경우에만 사용 합니다.

부울 값이 아니라 트리거 해야하는 작업이지만 상태 피드백이 필요하지 않은 경우 (즉시 200 OK 제외) RPC와 같이 엔드 포인트를 사용하여 RPC와 매우 유사하게 트리거합니다.

POST /subscriptions/{subscriptionid}/activate/

의심스러운 경우 다음을 읽으십시오 : http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#restful ( "CRUD 운영 세계에 맞지 않는 행동은 어떻습니까? ")

— 배리 스타즈
소스

REST가 작동하지 않습니다. Activate동사이고 상태 Active가 될 수 없으며 상태입니다.

RESTful은 작동하지 않기 때문에 RESTful 서비스에 수행 할 작업을 지시 할 수 없지만 서비스 큐에 대한 작업을 추가 할 수 있습니다.

이것 좀 봐:

PUT /subscriptionQueue
subscriptionId={subscriptionId}
active=true

이 요청은 RESTful이며 RESTful의 모든 이점 (성능, 산성 등)을 지원합니다.

— 피터 레이더
소스