왜 HATEOAS가 필요한 요청 수를 늘려야합니까? 서비스가 URI를 반환하지 않으면 클라이언트는 상태 트란지션을 수행하는 데 사용할 수 있습니다 (추가 정보 수집, 일부 작업 호출 ...). 클라이언트는 URI 자체를 작성하는 방법에 대한 지식이 있어야합니다 (따라서 서비스와 밀접하게 결합됩니다) 클라이언트가 여전히 서버 측에서 엔드 포인트를 호출해야합니다. 따라서 HATEOAS는 클라이언트에서 서버로 URI를 생성하는 방법에 대한 지식을 이전합니다.
일반적으로 서버에 전송 된 추가 요청은 실제로 각 호출이 상태가 없어야하므로 문제가되지 않습니다. 로드 균형 조정 된 서버 구조가있는 경우 추가 요청은 실제로 서버에 상당한 영향을 미치지 않습니다.
어떤 이유에서든 클라이언트가 서버에 요청한 요청 수에 신경을 쓰면 고객의 경우에도 하위 리소스의 콘텐츠를 포함시킬 수있는을 볼 수 있습니다. 주문은 사용자가 발급 된 주문을 많이 저장할 수있는 것처럼 응답이 상당히 클 수 있고 클라이언트가 사용하지 않을 수도 있지만 모든 데이터를 관리해야하는 것처럼 상당한 성능 영향을 미칠 수 있습니다. 일반적으로 응답 내에 많은 목록 항목을 포함하는 대신 서비스는 클라이언트가 필요한 경우이 정보를 검색하는 방법을 클라이언트가 알 수있는 URI를 가리 킵니다. 흔히 이런 종류의 URI는 (고객이 주문한 것과 같은) 페이지 뷰를 제공한다.
서비스가 처리 할 수있는 요청 수를 늘릴 수있는 페이지 가능 요청이 있지만 서비스가 전체 주문 데이터를 클라이언트에 반환 할 필요가 없으므로 전체 성능이 향상되므로 백업 DB의로드가 줄어 듭니다. 실제 응답 내용 길이가 줄어 듭니다.
내 게시물을 요약하기 위해 HATEOAS는 클라이언트에서 서버로 호출하기 위해 URI를 작성하는 논리를 변경하기 때문에 클라이언트가 서비스와 더 이상 분리됩니다. 클라이언트가 요청해야하는 실제 요청 수는 HATEOAS가 아니라 전체 API 디자인과 클라이언트의 요구 사항에 달려 있습니다.
오케이! URI가 서버에 의해 생성되고 클라이언트에 의해 정적으로 유지되지 않기 때문에 일부 고객 정보를 가져 오려면 몇 가지 추가 호출을 통과해야 할 수도 있습니다. 응답에서 서버로부터 해당 정보 URI를 얻을 때까지 경우 URI를 명중하고 리소스를 얻습니다. –