클라이언트 측에서 HATEOAS의 요점은 무엇입니까?

현재 이해합니다 HATEOAS는 기본적으로 각 응답 링크와 함께 다음에 수행 할 작업에 대한 정보를 보내는 것입니다. 하나의 간단한 예는 인터넷에서 쉽게 찾을 수 있습니다 : 계정 시스템과 은행 시스템. 이 예는 계정 리소스에 대한 GET 요청 후이 응답을 보여줍니다.

GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK 
<?xml version="1.0"?> 
<account> 
    <account_number>12345</account_number> 
    <balance currency="usd">100.00</balance> 
    <link rel="deposit" href="/account/12345/deposit" /> 
    <link rel="withdraw" href="/account/12345/withdraw" /> 
    <link rel="transfer" href="/account/12345/transfer" /> 
    <link rel="close" href="/account/12345/close" /> 
</account>

데이터와 함께 다음에 수행 할 수있는 작업을 알려주는 링크가 있습니다. 잔액이 음수이면

GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK 
<?xml version="1.0"?> 
<account> 
    <account_number>12345</account_number> 
    <balance currency="usd">-25.00</balance> 
    <link rel="deposit" href="/account/12345/deposit" /> 
</account>

입금 만 가능합니다. Fiddler를 사용하거나 브라우저로 요청하면 수행 할 수있는 작업을 쉽게 확인할 수 있습니다. 이런 종류의 정보는 API의 기능을 발견하고 서버가 클라이언트에서 분리되는 데 유용합니다.

그러나 요점은 우리가 Javascript를 사용하는 SPA, Android 앱 또는 다른 많은 것들과 같은 클라이언트를 구축 할 때 HATEOAS가 어떻게 계속 관련이 있는지 알 수 없다는 것입니다. 의미하는 바는 다음과 같습니다. SPA를 자바 스크립트로 코딩 할 때 코드를 작성하려면 API에서 수행 할 수있는 작업을 알아야합니다.

따라서 서버에 ajax 호출을 작성하고 심지어 UI를 빌드하기 위해 리소스, 지원되는 메소드, 수신 대상 및 반환 대상을 알아야합니다. UI를 만들 때 계정을 요청한 후 예를 들어 입금하거나 UI에서이 옵션을 제공 할 수 없다는 것을 알아야합니다. 또한 아약스 호출을 빌드하기 위해 예금을 만들기 위해 URI를 알아야합니다.

내 말은 API에 요청을 할 때 링크를 사용하면 API를 더 잘 발견하고 사용할 수 있지만 클라이언트를 만들 때 우리가 구축하는 앱은 단순히 링크를 보지 않고 자체적으로 렌더링하는 것입니다 올바른 UI와 올바른 아약스 호출을하십시오.

그렇다면 고객에게 HATEOAS가 어떻게 중요한가? 어쨌든 우리는 왜 HATEOAS를 귀찮게합니까?

우리가 구축하는 앱은 단순히 링크를 보지 않고 자체적으로 올바른 UI를 렌더링하고 올바른 아약스 호출을합니다.

사실, 이것이 바로 HATEOAS 가 UI 를 제공 할 것 입니다. 아니 무엇 가능하지만, 경우 는 가능하다. 질문에서 알 수 있듯이 HAL 과 같은 공식 HATEOAS 는 가능한 것을 나타내는 링크를 제공합니다. 그러나 경우에 해당 링크가 표시 응용 프로그램의 상태에 따라 달라집니다. 따라서 링크는 시간이 지남에 따라 리소스에서 변경 될 수 있습니다 (이미 수행 된 작업을 기반으로 함).

이를 통해 가능한 모든 상태 가 포함 된 UI를 만들 수 있지만 해당 상태가 활성화 되는 시점 에는 신경 쓰지 않습니다 . 예를 들어,의 존재 rel="deposit"는 UI가 make deposit양식 을 렌더링해도 괜찮을 때 UI에 직접 알릴 수 있습니다 . 그러면 사용자가 값을 입력하고 링크를 사용하여 제출할 수 있습니다.

현재 이해합니다 HATEOAS는 기본적으로 각 응답 링크와 함께 다음에 수행 할 작업에 대한 정보를 보내는 것입니다.

증오는 단순한 링크 그 이상입니다. 응용 프로그램 상태의 엔진으로서 "하이퍼 미디어"입니다.

설명에서 빠진 것은 클라이언트와 서버간에 전달되는 하이퍼 미디어의 공식적인 정의 인 컨텐츠 유형입니다.

HTML은 하이퍼 미디어의 예이며 HATEOS가 작동하는 이유의 예입니다. HTML 페이지 자체는 클라이언트 (예 : 사용자)가 사이트를 이동할 수 있도록하는 엔진입니다. HTML을 사용자에게 완전히 탐색 가능한 웹 사이트로 표시 할 수있는 기능을 갖춘 브라우저입니다. 단순히 다른 페이지에 대한 링크를 전달하는 것이 아니라 링크에 컨텍스트를 제공하고 브라우저가 탐색 가능한 사이트를 구성 할 수있는 방식으로 의미있는 방식으로 링크를 전달합니다.

그리고 가장 중요한 것은 브라우저가 웹 사이트 자체에 대한 ZERO의 사전 이해를 통해이를 수행 할 수 있다는 것입니다. 브라우저는 HTTP 및 HTML 만 알고 있습니다. 이러한 간단한 이해를 바탕으로 뉴욕 타임즈를 사용자에게 제시하여 탐색 할 수 있습니다.

"사용자"가 다른 컴퓨터 프로그램 인 경우에도 마찬가지입니다. 하이퍼 미디어 자체는 탐색 컨텍스트를 정의해야합니다.

동적으로 생성 된 인터페이스를 구축 할 필요가 없습니다. 좋을 수도 있지만 필요하지는 않습니다. 동적 인터페이스를 구축 할 수없는 경우 링크를 사용하면됩니다. 단점은 다시 백엔드에 하드 링크되어 있으며 변경 사항이 있으면 충돌한다는 것입니다.

동적 레이아웃을 사용하는 것은 매우 간단합니다.

links.forEach(function(link) {

  switch(link.rel) {

    case 'deposit':
      showDepositButton();
      break;

    case 'withdraw':
      loadWithdrawForm(link.href);
      showWithdrawButton();
      break;
  }

});

다음과 같이 클라이언트 코드에 저장됩니다.

if (balance <= 0 && negativeBalanceAllowed === false) {
  showWithdrawButton();
}

클라이언트를 변경하지 않고 허용 된 부정적 위치 (예 : 돈을 빌림)를 구현할 수 있습니다.