Hypermedia-Friendly Scripting

REST에 대한 제약 조건 집합에 최종적으로 추가된 것은 3.5.3절의 코드 온 디맨드 스타일에서 비롯됩니다(Figure 5-8). REST는 클라이언트 기능을 확장하기 위해 애플릿이나 스크립트 형태로 코드를 다운로드하고 실행하는 것을 허용합니다. 이는 사전에 구현해야 하는 기능의 수를 줄임으로써 클라이언트를 단순화합니다. 배포 후 기능을 다운로드할 수 있게 함으로써 시스템 확장성을 개선할 수 있습니다. 그러나 이는 가시성을 낮추기 때문에 REST 내에서 선택적인 제약 조건으로 간주됩니다.

-- Roy Fielding - 대표 상태 전송(REST)

#스크립팅과 웹

하이퍼미디어 기반 애플리케이션에서 우리는 웹 애플리케이션을 빌드하는 방법에 대해 논의합니다. 이 방법은 현재 인기를 끌고 있는 SPA 접근법과 달리 애플리케이션을 하이퍼미디어 기반으로 빌드하는 것입니다. SPA 접근법은 JavaScript 기반이며, 네트워크 수준에서 RPC 기반입니다.

HDA(Hypermedia-Driven Application) 문서에서 스크립팅에 대해 간단히 언급합니다:

HDA에서 하이퍼미디어(HTML)는 애플리케이션을 빌드하는 주요 매체이므로:

• 모든 서버와의 통신은 여전히 HTTP 요청과 하이퍼미디어(HTML) 응답을 통해 관리됩니다.
• 스크립팅은 애플리케이션의 프론트엔드 경험을 향상시키는 데 주로 사용됩니다.

스크립팅은 기존 하이퍼미디어(HTML)를 보완하지만, 이를 초월하거나 기본적인 REST-ful 아키텍처를 전복하지 않습니다.

이 기사에서는 이 마지막 언급을 확장하여 REST-ful, 하이퍼미디어 기반 애플리케이션을 초월하거나 전복하지 않는 스크립팅이 어떤 모습인지 설명하고자 합니다. 이 규칙들은 웹 애플리케이션을 지원하기 위해 직접 작성된 스크립팅뿐만 아니라 일반적인 JavaScript 라이브러리에도 적용됩니다.

하이퍼미디어 친화적인 스크립팅의 기본 규칙은 다음과 같습니다:

• HATEOAS를 존중하세요
• 클라이언트 측 상태는 허용됩니다
• 구성 요소 간 통신에 이벤트를 사용하세요
• 비하이퍼미디어 구성 요소를 애플리케이션의 다른 부분과 격리하기 위해 아일랜드를 사용하세요
• 선택적으로 인라인 스크립팅을 고려하세요

이 규칙들은 아래에서 더 자세히 설명됩니다.

#기본 원칙

HDA의 기본 원칙은 애플리케이션 상태의 엔진으로서의 하이퍼미디어(HATEOAS)를 사용하는 것입니다. 하이퍼미디어 친화적인 스크립팅 접근법은 이 원칙을 따릅니다.

실제로, 이는 스크립팅이 서버와의 비하이퍼미디어 네트워크 교환을 피해야 한다는 것을 의미합니다.

따라서 일반적으로 하이퍼미디어 친화적인 스크립팅은 서버에서 하이퍼미디어(예: HTML)를 사용한 응답이 아닌 데이터 API 형식(예: 단순 JSON)을 사용한 응답을 받는 fetch() 및 XMLHttpRequest 사용을 피해야 합니다.

HATEOAS를 존중한다는 것은 또한 JavaScript에 저장된 복잡한 상태(즉, DOM 외부에 저장된 상태)를 피해야 한다는 것을 의미합니다.

그러나 이 마지막 진술은 수정을 필요로 합니다: JavaScript에 상태를 클라이언트 측에 저장하는 것은 더 정교한 프론트엔드 경험(예: 위젯)을 직접 지원하는 경우 허용될 수 있습니다.

필딩이 REST에서 스크립팅의 목적에 대해 말한 것을 다시 강조하자면:

배포 후 기능을 다운로드할 수 있게 함으로써 시스템 확장성을 개선할 수 있습니다.

따라서 스크립팅은 하이퍼미디어(예: HTML)보다 더 많은 기능을 구현할 수 있도록 하여 하이퍼미디어를 더 확장 가능하게 만드는 REST-ful 시스템의 정당한 일부입니다.

이러한 기능의 좋은 예는 리치 텍스트 편집기입니다: 이 편집기는 선택 정보, 하이라이팅 정보, 코드 자동 완성 등을 포함한 문서의 매우 정교한 JavaScript 모델을 가질 수 있습니다. 그러나 이 모델은 나머지 DOM과 격리되어야 하며, 리치 텍스트 편집기는 콘텐츠를 가져오기 위해 JavaScript API 호출을 요구하는 것이 아니라, 표준 하이퍼미디어 기능을 사용하여 정보를 DOM에 노출해야 합니다. 예를 들어, 숨겨진 입력 필드를 사용하여 편집기의 내용을 주변 DOM에 전달해야 합니다.

아이디어는 스크립팅을 사용하여 하이퍼미디어 경험을 향상시키되, 많은 SPA 프레임워크가 하는 것처럼 HTML을 더 큰 JavaScript 애플리케이션 내의 단순한 UI 설명 언어로 전락시키지 않고 HTML과 잘 작동하는 방식으로 이를 수행하는 것입니다.

#state

애플리케이션 상태의 엔진으로서의 하이퍼미디어(HATEOAS)를 사용하는 것은 클라이언트 측 상태를 전혀 가질 수 없다는 것을 의미하지 않습니다. 위에서 언급한 리치 텍스트 편집기 예시는 클라이언트 측에 상당한 양의 상태를 가질 수 있습니다. 하지만 클라이언트 측 상태가 정당하고 하이퍼미디어 기반 애플리케이션과 완전히 일치하는 더 간단한 경우들도 있습니다.

예를 들어, 버튼이나 앵커를 클릭하여 다른 요소에 클래스를 추가하여 이를 보이도록 하는 간단한 가시성 토글을 고려해 보세요.

이 일시적인 클라이언트 측 상태는 하이퍼미디어 기반 애플리케이션에서 문제가 없습니다. 이 상태는 순전히 프론트엔드 상태이기 때문입니다. 만약 시스템 상태가 이 종류의 스크립팅과 함께 업데이트된다면(즉, 요소를 표시하거나 숨기는 것이 서버에 저장된 데이터에 영향을 미치는 경우), 하이퍼미디어 교환이 필요하게 됩니다.

고려해야 할 중요한 측면은 클라이언트 측에서 업데이트된 상태가 서버와 동기화되어야 하는지 여부입니다.
만약 그렇다면 하이퍼미디어 교환이 사용되어야 합니다. 그렇지 않다면 상태를 클라이언트 측에만 유지하는 것이 괜찮습니다.

#events

JavaScript 라이브러리가 하이퍼미디어 친화적인 스크립팅을 가능하게 하는 훌륭한 방법 중 하나는 풍부한 커스텀 이벤트 모델을 가지는 것입니다.

이벤트를 트리거하는 JavaScript 기반 구성 요소는 htmx와 같은 하이퍼미디어 지향 JavaScript 라이브러리가 이러한 이벤트를 듣고 하이퍼미디어 교환을 트리거할 수 있게 합니다. 이는 결과적으로 모든 JavaScript 라이브러리가 사용자가 선택한 동작을 통해 하이퍼미디어 기반 애플리케이션을 구동할 수 있는 _하이퍼미디어 컨트롤_이 될 수 있게 합니다.

그 예로 Sortable.js 예제를 들 수 있습니다. 여기서 htmx는 Sortable.js에서 트리거되는 end 이벤트를 듣습니다:

<form class="sortable" hx-post="/items" hx-trigger="end">
  <div class="htmx-indicator">Updating...</div>
  <div><input type='hidden' name='item' value='1'/>Item 1</div>
  <div><input type='hidden' name='item' value='2'/>Item 2</div>
  <div><input type='hidden' name='item' value='3'/>Item 3</div>
  <div><input type='hidden' name='item' value='4'/>Item 4</div>
  <div><input type='hidden' name='item' value='5'/>Item 5</div>
</form>

end 이벤트는 Sortable.js에서 드래그 앤 드롭이 완료될 때 트리거됩니다. htmx는 hx-trigger 속성을 통해 이 이벤트를 듣고 HTTP 요청을 발행하여 서버와 하이퍼미디어를 교환합니다. 이렇게 하면 Sortable.js를 사용하는 드래그 앤 드롭 기능이 강력한 하이퍼미디어 컨트롤로 변환됩니다.

#Islands

최근 웹 개발에서 주목받고 있는 트렌드 중 하나는 “아일랜드”라는 개념입니다:

아일랜드 아키텍처는 서버 렌더링된 웹 페이지 내에서 작은, 집중된 인터랙티브 요소들을 권장합니다.

더 정교한 스크립팅 접근이 필요하고, 정상적인 하이퍼미디어 교환 메커니즘 외부의 서버와의 통신이 필요한 경우, 가장 하이퍼미디어 친화적인 접근은 아일랜드 아키텍처를 사용하는 것입니다. 이를 통해 비하이퍼미디어 요소를 하이퍼미디어 기반 애플리케이션의 나머지 부분과 격리할 수 있습니다.

이벤트는 비하이퍼미디어 기반의 아일랜드를 더 넓은 하이퍼미디어 기반 애플리케이션 내에서 통합하는 깔끔한 방법으로, 위에서 설명한 Sortable.js 예제처럼 “내부” 아일랜드를 “외부” 하이퍼미디어 컨트롤로 변환할 수 있게 합니다.

Deniz Akşimşek는 비하이퍼미디어 아일랜드를 더 큰 하이퍼미디어 기반 애플리케이션 내에 포함하는 것이 반대의 경우보다 일반적으로 더 쉽다는 점을 관찰했습니다.

#인라인 스크립트

하이퍼미디어 친화적인 스크립팅을 위한 마지막 규칙은 인라인 스크립팅입니다. 이는 하이퍼미디어 내에 직접 스크립트를 작성하는 것이며, 외부 파일에 스크립트를 배치하는 것과는 다릅니다. 이는 여기서 언급된 다른 개념들에 비해 논란이 될 수 있으며, 하이퍼미디어 친화적인 스크립팅을 위한 “선택적” 규칙으로 간주됩니다: 고려해볼 만하지만 필수는 아닙니다.

이러한 스크립팅 접근법은 독특하지만, 일부 HTML 스크립팅 라이브러리, 특히 Alpine.js와 hyperscript에서 채택되었습니다.

다음은 인라인 스크립트를 보여주는 hyperscript의 예입니다:

<button _="on click toggle .visible on the next <section/>">
    다음 섹션 표시
</button>
<section>
    ....
</section>

이 버튼은 클릭할 때 section 요소의 .visible 클래스를 토글합니다.

이러한 인라인 스크립팅 접근의 주요 장점은 개념적으로 하이퍼미디어 자체가 강조된다는 점입니다. 이는 하이퍼미디어 스크립팅보다 더 강조됩니다.

이 코드를 JSX Components와 비교해보면, 스크립팅 언어(JavaScript)가 핵심 개념이며, 하이퍼미디어/HTML이 그 안에 포함되어 있는 방식입니다:

class Button extends React.Component {
    constructor(props) {
        // ...
    }
    toggleVisibilityOnNextSection() {
        // ...
    }
    render() {
        return <button onClick={this.toggleVisibilityOnNextSection}>{this.props.text}</button>;
    }
}

여기서 JavaScript가 주로 사용되는 기술이며, 하이퍼미디어/HTML은 UI 설명 메커니즘으로 사용됩니다. 이 경우, HTML이 하이퍼미디어라는 사실은 거의 중요하지 않습니다.

그럼에도 불구하고, 인라인 스크립팅과 JSX 접근법은 공통된 장점을 공유합니다: 둘 다 행동의 지역성(LoB) 원칙을 충족합니다. 이들은 모두 요소나 구성 요소에 대한 행동을 지역화 하여 이러한 요소와 구성 요소가 무엇을 하는지 쉽게 알 수 있게 만듭니다.

물론, 인라인 스크립트의 경우, 하이퍼미디어 내에서 직접 수행되는 스크립팅의 양에 대한 적절한 한계가 있어야 합니다. 스크립팅이 너무 많아져 하이퍼미디어 문서의 “형태“를 이해하기 어려워지지 않도록 주의해야 합니다.

라이브러리 함수를 호출하거나 hyperscript behaviors를 사용하는 등의 기법을 통해 인라인 스크립팅을 사용하면서도 구현을 별도의 파일이나 위치로 분리할 수 있습니다.

인라인 스크립팅은 하이퍼미디어 친화적인 스크립팅에 필수는 아니지만, 전통적인 스크립팅/하이퍼미디어 분리와는 대안으로 고려해볼 만합니다.

#실용주의

물론, 현실 세계에서는 HATEOAS를 위반하고 이벤트를 트리거하지 않는 유용한 JavaScript 라이브러리가 많이 있습니다. 이는 종종 하이퍼미디어 기반 애플리케이션에 적합하지 않은 경우가 많습니다. 그럼에도 불구하고, 이러한 라이브러리는 다른 곳에서 찾기 어려운 중요한 기능을 제공할 수 있습니다.

이러한 경우, 실용주의를 권장합니다: 라이브러리를 하이퍼미디어 친화적으로 변경하거나 하이퍼미디어 친화적인 방식으로 감싸는 것이 쉽다면, 그것이 좋은 선택이 될 수 있습니다. 예상하지 못한 곳에서, 업스트림 작성자가 풀 리퀘스트를 고려할 수도 있습니다.

하지만, 그렇지 않고 좋은 대안이 없다면, JavaScript 라이브러리를 설계된 대로 사용하십시오.

하이퍼미디어 친화적이지 않은 라이브러리를 애플리케이션의 나머지 부분과 격리하려고 노력하되, 개념적 순수성을 유지하기 위해 복잡성 예산을 너무 많이 소모하지 않도록 하십시오: 그날에 충분한 악은 그것으로 족합니다.