편안한 자원 표현에 하위 항목을 포함시킬 때?

Question

편안한 디자인은 평평하거나 얕은 구조화 된 표현을 옹호하는 것으로 보입니다 (적어도 자원이 XML로 표시 될 때). 리소스 표현에는 URI가 식별하는 리소스 만 포함되어야합니다. 부모 리소스 내에 자원의 하위 자원을 제시하는 것이 현명한 지 궁금합니다.

자세히 설명하려면 다음을 고려하십시오. 회사에는 여러 명의 직원이있을 수 있습니다. 일반적 으로이 상황은 직원이 회사의 하위 자원이 될 두 개의 별도 자원 인 회사와 직원으로 설계 될 것입니다.

/company/acme/
/company/acme/employees/
/company/acme/employee/john

이 URI 디자인을 사용하면 회사 표현에는 직원에 대한 링크가 포함되어야하지만 XML 표현에는 Emplyoyees 자체가 포함되지 않을 것입니다.

따라서 부모를 통해 언제 하위 항목이 의미가 있습니까? 그리고 하위 항목을 제시하는 것이 현명한 상황이 있습니까? 뿐 부모를 통해. 나는 하위 항목에 대한 URI가 전혀 없다는 것을 의미합니다. 부모 자원을 통해서만 도달 할 수 있습니다.

<company>
<name>Acme</name>
 <employees>
  <employee>John</employee>
  <employee>Jack</employee>
 </employees>
</company>

리소스에 액세스하기 위해 하나의 방법 만 제공하는 것이 합리적입니까? 부모가 하위 항목을 노출시키는 경우 하위 항목에 대한 명시 적 URI도있을 수 있습니까? 따라서 회사의 XML에 회사의 직원이 포함되어 있다면 회사 자원을 통해 동일한 정보를 얻을 수 있다는 것을 제공/회사/ACME/직원 URI 분실하는 것이 합리적입니까?

Answer 1

하위 자원이 부모의 맥락에서만 의미가있는 경우, 그렇습니다. 부모 내에 중첩되게 반품해야합니다. 예를 들어, html에서 <li> 요소는 자체적으로 하위 자원으로 의미가 없습니다.

그러나 리소스가 혼자 서있을 수 있고 다른 리소스와 무관하게 리소스를 조작하려는 경우 자체 URI가 있어야합니다. 이렇게하면 다른 관련 리소스에 영향을 미치지 않고 서버로 돌려받지 않고도 해당 리소스를 게시하거나 게시 할 수 있습니다. 부모로부터 모든 것을 조작해야한다면, 한 사람이 얻을 수 있다면 어떤 일이 발생하는지 생각하고, 하위 항목을 수정 한 다음 해당 하위 항목이 변경된 상태에서 모든 일을 수행합니다. 그 동안 다른 사람이 다른 사람 중 하나를 변경하면 어떻게됩니까? 그런 다음 자물쇠와 트랜잭션 의미론을 추가해야하므로 휴식의 전체 무국적을 물리칩니다.

GET 요청은 적어도 클라이언트가 한 번에 많은 수의 리소스를 얻을 수있는 일부 형태의 벌크 쿼리 인터페이스를 갖는 것이 좋습니다. 각 리소스에 대해 새로운 HTTP 요청을 수행 해야하는 데는 오랜 시간이 걸릴 수 있습니다. 각 GET에 대한 네트워크를 통한 새로운 왕복을 의미하기 때문입니다. 대량 업데이트 기능을 갖는 것이 합리적 일 수 있습니다. 그러나 한 번에 하나의 리소스를 조작하려면 해당 리소스에 대한 URI를 제공해야합니다.

그렇습니다. 리소스에 액세스 할 수있는 방법을 여러 가지 이상 있으면 완벽합니다. 블로그처럼 생각할 수 있습니다. 메인 페이지 나 아카이브 페이지에서 또는 Permalink로 이동하여 스토리를 얻을 수 있습니다.

편집하다: 한 명의 클라이언트가 서버에 오래된 데이터를 제공하는 문제를 해결하지 않고 대량 업데이트를 원한다면 기본적으로 두 가지 옵션이 있습니다.

1. 잠금. 한 클라이언트는 서버에 "이 전체 데이터 세트에 잠금을 원한다"고 말하고, 수정하려는 데이터를 가져오고, 데이터를 수정하고, 서버로 다시 보내고, 잠금을 해제합니다.
2. 낙관적 동시성: 클라이언트는 데이터 세트를 다운로드하여 새 데이터를 얻을 때마다 서버가 변경되는 일종의 개정 태그가 표시됩니다. 클라이언트는이를 수정하고 서버로 다시 보냅니다. 그 동안 세트의 다른 데이터가 수정 된 경우 개정 태그가 데이터를 벗어나고 서버는 "죄송합니다. 데이터가 오래되지 않았으며 다시 시도하십시오".

이들 각각에는 장점과 함정이 있습니다. 잠금의 문제는 그것이 상태가 많기 때문에 REST 아키텍처에 잘 맞지 않는다는 것입니다. 클라이언트 프로그램이 잠금 장치가있는 동안 충돌하거나 다른 방식으로 사망하면, 어떤 종류의 잠금 시간 초과가 없으면 해당 데이터가 영구적으로 잠겨 있습니다. 이는 까다로울 수 있습니다. 고객이 여러 자물쇠가 포함 된 멋진 거래를 수행하는 경우 잠금 장치가 교착 상태로 이어질 수 있습니다.

낙관적 동시성의 문제점은 데이터 세트에 높은로드가 있고 많은 클라이언트가 한 번에 변경하면 주어진 클라이언트가 데이터를 게시하기 전에 많은 시도가 필요하다는 것입니다. 실제로, 느린 클라이언트는 다른 클라이언트가 느린 클라이언트가 항상 실패한다는 것을 의미하는 방식으로 데이터를 지속적으로 변경하기 때문에 느린 클라이언트가 업데이트 게시에서 완전히 차단 될 수 있습니다.

이 옵션 중 어떤 옵션이 귀하에게 적합한 지 스스로 결정해야합니다. 이러한 문제는 단일 리소스를 변경할 때도 발생하지만 (한 번의 업데이트는 다른 업데이트가 다른 것일 수 있습니다), 리소스를 대량 인터페이스로 집계하면 훨씬 더 자주 나타날 것입니다. 그렇기 때문에 자원을 집계하려는 경우 두 개의 인터페이스를 사용하는 것이 좋습니다. 리소스에 개별적으로 액세스 할 수있는 것과 많은 리소스를 한 번에 읽고 쓸 수있는 선택적 벌크 인터페이스.