이 기사 에서 저자는

때로는 본질적으로 RESTful하지 않은 작업을 API에 노출해야하는 경우가 있습니다.

그리고

API에 작업이 너무 많으면 RESTful 원칙을 사용하지 않고 RPC 관점으로 설계되었거나 해당 API가 자연스럽게 RPC 유형 모델에 더 적합하다는 것을 나타냅니다.

이것은 내가 읽고 다른 곳에서들은 것을 반영합니다.

그러나 나는 이것이 매우 혼란스럽고 문제에 대해 더 잘 이해하고 싶습니다.

예 I : REST 인터페이스를 통해 VM 종료

VM 종료를 모델링하는 근본적으로 다른 두 가지 방법이 있다고 생각합니다. 각 방법마다 약간의 차이가있을 수 있지만 현재 가장 근본적인 차이점에 집중 해 봅시다.

1. 자원의 상태 속성 패치

PATCH /api/virtualmachines/42
Content-Type:application/json  

{ "state": "shutting down" }

(또는 PUT하위 리소스 /api/virtualmachines/42/state에서)

VM은 백그라운드에서 종료되며 종료 여부에 따라 나중에 "전원 끄기"로 상태가 내부적으로 업데이트 될 수 있습니다.

2. 자원의 action 속성에서 PUT 또는 POST

PUT /api/virtualmachines/42/actions
Content-Type:application/json  

{ "type": "shutdown" }

결과는 첫 번째 예와 정확히 동일합니다. 상태는 즉시 "shuting down"으로 업데이트되고 결국 "power off"로 업데이트됩니다.

두 디자인 모두 RESTful입니까?

어떤 디자인이 더 낫습니까?

예 II : CQRS

여러 집계를 업데이트하거나 구체적 자원 및 하위 자원에 대한 CRUD 오퍼레이션에 맵핑 할 수없는 많은 "조치"(일명 명령)가있는 CQRS 도메인이있는 경우 어떻게됩니까?

가능한 한 구체적 자원에 대해 구체적 명령을 작성하거나 업데이트하는 것 (예제 I의 첫 번째 접근법에 따름)만큼 많은 명령을 모델링하고 나머지는 "작업 종점"을 사용해야합니까?

아니면 모든 명령을 작업 끝점에 매핑해야합니까 (예 I의 두 번째 접근 방식과 같이)?

우리는 어디에 선을 그려야합니까? 디자인이 덜 RESTful 한시기는 언제입니까?

CQRS 모델이 RPC 유사 API에 더 적합합니까?

위의 인용 된 텍스트에 따르면 이해합니다.

많은 질문에서 알 수 있듯이이 주제에 대해 약간 혼란 스럽습니다. 더 잘 이해하도록 도와 줄 수 있습니까?

첫 번째 경우 (VM 종료), OP 대안 중 RESTful을 고려하지 않습니다. 물론 Richardson 성숙도 모델 을 척도로 사용하는 경우 리소스와 동사를 사용하기 때문에 2 API 가 모두 사용됩니다.

그러나 둘 다 하이퍼 미디어 컨트롤을 사용하지 않으며 RESTful API 디자인을 RPC 와 차별화 하는 유일한 유형의 REST입니다 . 다시 말해, 레벨 1과 2를 고수하면 대부분의 경우 RPC 스타일 API를 갖게됩니다.

VM을 종료하는 두 가지 방법을 모델링하기 위해 VM 자체를 링크가 포함 된 리소스로 표시합니다.

{
    "links": [{
        "rel": "shut-down",
        "href": "/vms/1234/fdaIX"
    }, {
        "rel": "power-off",
        "href": "/vms/1234/CHTY91"
    }],
    "name": "Ploeh",
    "started": "2016-08-21T12:34:23Z"
}

클라이언트가 종료하고자하는 경우 PloehVM을, 그것은한다고 링크 따라 와 shut-down관계 유형을. (일반적으로 RESTful Web Services Cookbook에 설명 된대로 관계 유형에 대해 IRI 또는보다 정교한 식별 체계를 사용하지만 가능한 한 간단한 예를 유지하기로 선택했습니다.)

이 경우 조치를 제공 할 다른 정보가 거의 없으므로 클라이언트는 다음의 URL에 대해 빈 POST를 작성해야합니다 href.

POST /vms/1234/fdaIX HTTP/1.1

(이 요청에는 본문이 없으므로 GET 요청으로 모델링하려는 유혹이 있지만 GET 요청에는 부작용이 없어야하므로 POST가 더 정확합니다.)

마찬가지로 클라이언트가 VM의 전원을 끄려면 power-off대신 링크를 따라갑니다 .

즉, 링크의 관계 유형은 의도를 나타내는 여유 를 제공합니다 . 각 관계 유형에는 특정한 의미 론적 의미가 있습니다. 이것이 우리가 때때로 시맨틱 웹 에 대해 이야기하는 이유 입니다.

예제를 최대한 명확하게 유지하기 위해 각 링크의 URL을 의도적으로 숨겼습니다. 호스팅 서버가 들어오는 요청을 받으면 알아 줄 fdaIX수단이 종료 하고, CHTY91수단의 전원을 끕니다 .

일반적으로 URL 자체에 작업을 인코딩하여 URL이 /vms/1234/shut-down및 /vms/1234/power-off이지만 교육시 관계 유형 (시맨틱)과 URL (구현 세부 사항)의 구분이 흐려집니다.

보유한 클라이언트에 따라 RESTful URL을 해킹 불가능하게 만드는 것을 고려할 수 있습니다 .

CQRS

CQRS와 관련하여 Greg Young과 Udi Dahan이 동의하는 몇 가지 사항 중 하나는 CQRS가 최상위 아키텍처가 아니라는 것 입니다. 따라서 RESTful API를 너무 CQRS와 같이 만드는 것은 조심해야합니다. 이는 클라이언트가 아키텍처의 일부가됨을 의미하기 때문입니다.

실제 (레벨 3) RESTful API의 원동력은 클라이언트를 중단하지 않고 클라이언트를 제어하지 않고도 API를 발전시킬 수 있기를 원한다는 것입니다. 그것이 당신의 동기라면, CQRS는 나의 첫번째 선택이 아닐 것입니다.

REST 인터페이스를 통해 VM 종료

이것은 실제로 2009 년 Tim Bray 가 제시 한 다소 유명한 예 입니다.

로이 필딩 (Roy Fielding)은 문제를 논의하면서이 관찰을 공유했다 .

개인적으로 모니터링되는 상태 (예 : 전원 상태)를 편집 할 수없는 시스템으로 선호합니다.

요컨대, 모니터 된 상태의 현재 표시를 리턴하는 하나의 정보 자원이 있습니다. 해당 표현에는 해당 상태에 대한 변경을 요청 하는 양식에 대한 하이퍼 미디어 링크가 포함될 수 있으며 양식에는 각 변경 요청을 처리 할 자원에 대한 다른 링크가 있습니다.

세스 래드 는 문제에 대한 핵심 통찰력을 가지고있었습니다

우리는 달리는 사람의 단순한 상태에서 생성, 업데이트 및 이야기 할 수있는 진정한 명사로 전환했습니다.

이것을 다시 컴퓨터 재부팅으로 가져갑니다. 나는 당신이 POST 것이라고 주장 할 것이다 / VDC / 434 / 클러스터 / 4894 / 서버 / 4343 / 재부팅 당신이 게시 한 후에는 나타내는 URI가 이 재부팅하고 상태 업데이트를 얻을 수 있습니다. 하이퍼 링크의 마법을 통해 재부팅 표시는 재부팅 된 서버에 연결됩니다.

유감 URI 공간은 저렴하고 URI는 훨씬 저렴하다고 생각합니다. 명사로 모델링 된 활동 콜렉션을 작성하고 POST, PUT 및 DELETE를 수행하십시오!

RESTful 프로그래밍은 웹 규모의 Vogon 관료주의입니다. 당신은 어떻게해야합니까 아무것도 편안하고 있습니까? 새로운 서류를 발명하고 서류를 디지털화하십시오.

좀 더 멋진 언어로, 당신이하고있는 일은 "VM 종료"를위한 도메인 애플리케이션 프로토콜 을 정의하고 그 프로토콜을 노출 / 구현하는데 필요한 리소스를 식별하는 것입니다.

자신의 예를 보면

PATCH /api/virtualmachines/42
Content-Type:application/json  

{ "state": "shutting down" }

괜찮아; 실제로 요청 자체를 별도의 정보 리소스로 취급하지는 않지만 여전히 관리 할 수는 있습니다.

당신은 변화의 표현에서 약간을 놓쳤다.

그러나 PATCH를 사용하면 동봉 된 엔터티에 현재 원본 서버에있는 리소스를 수정하여 새 버전을 생성하는 방법을 설명하는 지침 세트가 포함됩니다.

예를 들어 JSON 패치 미디어 유형은 JSON 문서를 직접 수정하는 것처럼 지시 사항을 형식화합니다.

[
    { "op": "replace", "path": "state", "value": "shutting down" }
]

대안으로, 아이디어는 가깝지만 분명히 정확하지는 않습니다. PUT는 대상 URL 의 리소스 상태를 완전히 대체 하므로 단일 엔티티 의 표현 대상으로 모음 처럼 보이는 철자를 선택하지 않을 것입니다 .

POST /api/virtualmachines/42/actions

대기열에 작업을 추가한다는 허구와 일치

PUT /api/virtualmachines/42/latestAction

큐의 테일 항목을 업데이트한다는 허구와 일치합니다. 이런 식으로하는 것이 조금 이상합니다. 최소한의 놀람 원칙은 각 PUT에 한곳에 모두 배치하고 동시에 여러 리소스를 수정하는 대신 고유 한 식별자를 부여하는 것이 좋습니다.

URI의 철자를 설명하는 한 REST는 신경 쓰지 않습니다. /cc719e3a-c772-48ee-b0e6-09b4e7abbf8bREST에 관한 한 완벽하게 cromulent URI입니다. 변수 이름과 마찬가지로 가독성은 별도의 관심사입니다. 와 일치하는 철자를 사용하여 RFC 3986을 만들 것입니다 사람들이 많은 행복.

CQRS

여러 집계를 업데이트하거나 구체적 자원 및 하위 자원에 대한 CRUD 오퍼레이션에 맵핑 할 수없는 많은 "조치"(일명 명령)가있는 CQRS 도메인이있는 경우 어떻게됩니까?

CQRS의 Greg Young

CQRS는 존재하지 않을 수있는 아키텍처에 대한 많은 기회를 가능하게하는 매우 간단한 패턴입니다. CQRS는 최종 일관성이 아니며, 이벤트가 아니며, 메시징이 아니며, 읽기 및 쓰기를위한 별도의 모델이 없으며, 이벤트 소싱을 사용하지도 않습니다.

대부분의 사람들이 CQRS에 대해 이야기 할 때 실제로 응용 프로그램의 서비스 경계를 ​​나타내는 개체에 CQRS 패턴을 적용하는 것에 대해 말합니다.

HTTP / REST의 맥락에서 CQRS에 대해 이야기하고 있다고 가정하면, 후자의 맥락에서 작업하고 있다고 가정하는 것이 합리적입니다.

놀랍게도 이것은 이전 예보다 훨씬 쉽습니다. 그 이유는 간단합니다. 명령은 메시지 입니다.

Jim Webber 는 HTTP를 1950 년대 사무실의 애플리케이션 프로토콜로 설명합니다. 메시지를 받아받은 편지함에 넣어서 작업이 완료됩니다. 같은 아이디어가 있습니다-양식의 빈 사본을 가져 와서 우리가 알고있는 내용으로 채우고 전달하십시오. 타 다

가능한 한 구체적 자원에 대해 구체적 명령을 작성하거나 업데이트하는 것 (예제 I의 첫 번째 접근법에 따름)만큼 많은 명령을 모델링하고 나머지는 "작업 종점"을 사용해야합니까?

예. "콘크리트 리소스"가 도메인 모델의 엔터티가 아닌 메시지 인 한 가능합니다.

핵심 아이디어 : REST API는 여전히 인터페이스입니다 . 클라이언트가 메시지를 변경할 필요없이 기본 모델을 변경할 수 있어야합니다. 새 모델을 릴리스하면 도메인 프로토콜을 가져 와서 새 모델에 적용하는 방법을 알고있는 웹 엔드 포인트의 새 버전을 릴리스합니다.

CQRS 모델이 RPC 유사 API에 더 적합합니까?

실제로는 아닙니다. 특히 웹 캐시는 "최종적으로 일관된 읽기 모델"의 좋은 예입니다. 각각의 캐싱 규칙을 사용하여 각각의보기를 독립적으로 처리 할 수있게하면 무료로 다양한 확장이 가능합니다. 읽기 전용 RPC 접근 방식에는 상대적으로 호소력이 없습니다.

쓰기의 경우 까다로운 질문입니다. 모든 명령을 단일 엔드 포인트 또는 단일 엔드 포인트 제품군의 단일 핸들러로 보내는 것이 훨씬 쉽습니다 . REST는 실제로 엔드 포인트가 클라이언트와 통신하는 위치를 찾는 방법에 대한 것입니다.

메시지를 고유 한 리소스로 취급하면 PUT을 사용할 수 있다는 장점이 있으며 중간 구성 요소에 메시지 처리가 dem 등이므로 특정 오류 처리에 참여할 수 있다는 사실을 알려줍니다. . (참고 : 클라이언트의 관점에서 볼 때 자원이 다른 URI를 가진 경우 자원이 다릅니다. 원본 서버에서 모두 동일한 요청 처리기 코드를 가질 수 있다는 사실은 유니폼에 의해 숨겨진 구현 세부 사항입니다. 인터페이스).

수비 (2008)

또한 위의 용어는 아직 완전히 RESTful하지는 않지만 적어도 용어를 사용하는 방법에 유의하십시오. 내가 한 모든 서비스 인터페이스는 RPC에 지나지 않습니다. RESTful하게하려면 서비스를 소개하고 정의하기 위해 하이퍼 텍스트를 추가하고, 양식 및 / 또는 링크 템플릿을 사용하여 매핑을 수행하는 방법을 설명하고, 시각화를 유용한 방식으로 결합하는 코드를 제공해야합니다.

당신이 활용할 수있는 미디어 타입의 5 단계를 요청의 content-type 헤더 필드에 명령을 지정할 수 있습니다.

VM 예제에서는 다음 라인을 따라 표시됩니다.

PUT /api/virtualmachines/42
Content-Type:application/json;domain-model=PowerOnVm

> HTTP/1.1 201 Created
Location: /api/virtualmachines/42/instance

그때

DELETE /api/virtualmachines/42/instance
Content-Type:application/json;domain-model=ShutDownVm

또는

DELETE /api/virtualmachines/42/instance
Content-Type:application/json;domain-model=PowerOffVm

https://www.infoq.com/articles/rest-api-on-cqrs를 참조 하십시오

링크 된 기사의 예제는 머신을 시작하고 종료하는 것이 모델링 된 자원 상태의 변경이 아니라 명령으로 지시되어야한다는 아이디어를 전제로합니다. 후자는 REST가 살고 호흡하는 것입니다. VM을 더 잘 모델링하려면 실제 상대방이 작동하는 방식과 사람이 사람과 어떻게 상호 작용하는지 살펴보십시오. 이것은 오래 걸리지 않았지만 훌륭한 모델링을 수행하는 데 필요한 사고 유형에 대한 통찰력을 제공한다고 생각합니다.

내 책상에서 컴퓨터의 전원 상태를 제어하는 ​​방법에는 두 가지가 있습니다.

• 전원 스위치 : 전원 공급 장치로의 전기 흐름을 즉시 차단하여 전체 컴퓨터를 갑자기 무질서하게 정지시킵니다.
• 온 / 오프 버튼 : 하드웨어가 외부의 모든 것이 종료되기를 원한다는 것을 소프트웨어에 알리도록 지시합니다. 소프트웨어는 순서대로 종료하고 완료된 하드웨어에 알리고 하드웨어는 전원 공급 장치에 대기 상태가 될 수 있음을 알립니다. 전원 스위치가 켜져 있고 기기가 작동 중이고 소프트웨어가 종료 신호에 응답 할 수없는 상태 인 경우 전원 스위치를 끄지 않으면 시스템이 종료되지 않습니다. (VM은 정확히 같은 방식으로 작동합니다. 소프트웨어에서 종료 신호를 무시하면 머신이 계속 실행되고 강제로 전원을 꺼야합니다.) 머신을 다시 시작하려면 머신을 다시 시작해야합니다. 전원 스위치를 다시 켠 다음 켜기 / 끄기 버튼을 누릅니다. (대부분의 컴퓨터에는 전원 버튼을 길게 눌러 대기 상태로 바로 이동할 수있는 옵션이 있습니다. 이 모델은 실제로 필요하지 않습니다.)이 버튼은 누를 때의 상태에 따라 다르게 동작하기 때문에 토글 스위치처럼 취급 될 수 있습니다. 전원 스위치가 꺼져 있으면이 버튼을 눌러도 아무 반응이 없습니다.

VM의 경우 두 가지 모두 읽기 / 쓰기 부울 값으로 모델링 할 수 있습니다.

• power-로 변경 true하면 스위치가이 상태로 설정되었다는 메모 외에는 아무 것도 발생하지 않습니다. 로 변경 false하면 VM은 즉시 전원 끄기 상태가됩니다. 완전성을 위해, 쓰기 후에 값이 변경되지 않으면 아무 일도 일어나지 않습니다.

• onoff-로 변경 true하면 poweris false인 경우 아무 일도 일어나지 않으며 , 그렇지 않으면 VM이 시작하라는 명령을받습니다. 로 변경 false되면 poweris false인 경우 아무 것도 발생하지 않습니다 . 그렇지 않으면 VM에 소프트웨어에 명령하여 시스템 종료를 지시하고 명령을 수행 한 후 VM에 전원 꺼짐 상태가 될 수 있음을 알립니다. 다시 말해, 완전성을 위해 변경없는 쓰기는 아무 작업도 수행하지 않습니다.

이 모든 것은 머신의 상태가 스위치의 상태를 반영하지 않는 한 가지 상황이 존재한다는 것을 깨달았습니다. power계속 될 것입니다 true및 onoff있을 것입니다 false만, 프로세서는 여전히 종료를 실행하고, 우리는 또 다른 자원을 추가 할 필요가 있음을 위해 우리는 기계가 실제로 무엇을하고 있는지 알 수 있습니다 :

• runningtrue-VM이 실행 중이거나 false그렇지 않은 경우 하이퍼 바이저의 상태를 요청하여 결정되는 읽기 전용 값입니다 .

이것의 결론은 VM을 시작하려면 power및 onoff리소스가 설정되어 있는지 확인해야한다는 것입니다 true. ( power단계를 자동 재설정 하여 단계를 건너 뛸 수 있도록으로 설정 하면 VM이 실제로 하드 중지 된 후에 단계 false가됩니다 true. RESTful-Pure가해야 할 일인지 다른 토론의 여지가 있습니다.) 당신이 순서대로 종료를 수행하려는 경우, 당신은 설정 onoff에 false설정하고 기계가 실제로 중지 된 경우 나중에 다시 와서 power에 false그것을하지 않았다합니다.

실제 환경과 마찬가지로 VM을 onoff변경 한 후에도 VM을 시작하라는 지시 가 false있지만 여전히 running종료 중이기 때문에 발생합니다. 이를 다루는 방법은 정책 결정입니다.

두 디자인 모두 RESTful입니까?

당신이 편안하게 생각하고 싶다면 명령에 대해 잊어 버려요. 클라이언트는 서버에게 VM을 종료하라고 지시하지 않습니다. 클라이언트는 상태를 업데이트하여 자원 표현의 사본을 "다우트 종료"(비 유적으로 말하기) 한 다음 서버에서 해당 표현을 다시 PUT합니다. 서버는 새로운 상태 표현을 받아들이고 이것의 부작용으로 실제로 VM을 종료합니다. 부작용은 서버에 맡겨져 있습니다.

이하

안녕하세요, 서버입니다. VM을 종료 하시겠습니까?

그리고 더

안녕하세요, 서버입니다. 여기에서 리소스 VM 42의 상태를 종료 상태로 업데이트 하고이 리소스의 복사본을 업데이트 한 다음 적절하다고 생각하는 작업을 수행하십시오.

이 새로운 상태를 받아들이는 서버의 부작용으로 실제로 수행해야하는 작업 (예 : VM 42를 물리적으로 종료)을 확인할 수 있지만 이는 클라이언트에게 투명합니다. 클라이언트는 서버가이 새로운 상태와 일관성을 유지하기 위해 취해야 할 조치에 대해 걱정하지 않습니다.

따라서 명령은 잊어 버리십시오. 유일한 명령은 상태 전송을위한 HTTP 동사입니다. 클라이언트는 서버가 물리적 VM을 종료 상태로 만드는 방법을 모릅니다. 클라이언트는 이것을 달성하기 위해 서버에 명령을 내리지 않고 단지 이것이 새로운 상태 라는 것을 말하고 있습니다.

이것의 장점은 흐름 제어 측면에서 서버와 클라이언트를 분리한다는 것입니다. 나중에 서버가 VM과 작동하는 방식을 변경하면 클라이언트는 신경 쓰지 않습니다. 업데이트 할 명령 엔드 포인트가 없습니다. RPC에서 API 엔드 포인트를에서 shutdown로 변경하면 shut-down이제 서버에서 호출 할 명령을 모르기 때문에 모든 클라이언트가 손상되었습니다.

REST는 선언적 프로그래밍과 유사합니다. 여기서 명령을 변경하는 명령 세트를 나열하는 대신 원하는 방식을 설명하고 프로그래밍 환경이이를 이해할 수 있도록합니다.