RESTful API 런타임 검색 기능 / HATEOAS 클라이언트 디자인

내가 관여하는 SaaS 스타트 업의 경우 RESTful 웹 API와이를 사용하는 서로 다른 플랫폼에서 몇 가지 클라이언트 앱을 모두 구축하고 있습니다. API를 알아 낸 것 같지만 이제는 클라이언트로 향하고 있습니다. REST에 대해 읽으면서 REST의 핵심 부분이 발견이라는 것을 알지만 발견이 실제로 무엇을 의미하는지에 대한 두 가지 다른 해석 사이에 많은 논쟁이있는 것 같습니다.

1. 개발자 검색 : 개발자는 리소스 URI, 쿼리 매개 변수, 지원되는 HTTP 메서드 및 문서를 탐색하고 API의 응답을 실험하여 발견 한 기타 세부 정보와 같은 방대한 양의 API 세부 정보를 클라이언트에 하드 코딩합니다. 이러한 유형의 발견 IMHO는 멋진 연결과 API 버전 관리 질문을 필요로하며 클라이언트 코드를 API에 하드 커플 링하게합니다. 잘 문서화 된 RPC 컬렉션을 사용하는 것보다별로 좋지 않습니다.

2. 런타임 검색 -클라이언트 앱 자체는 대역 외 정보가 거의 또는 전혀없이 필요한 모든 것을 파악할 수 있습니다 (아마 API가 처리하는 미디어 유형에 대한 지식 만 있음). 링크가 뜨거울 수 있습니다. 그러나 API를 매우 효율적으로 만들기 위해서는 쿼리 매개 변수에 대한 많은 링크 템플릿이 필요한 것 같습니다. 이로 인해 대역 외 정보가 다시 들어옵니다. 아직 생각하지 못한 다른 어려움이있을 수 있습니다. 개발 단계에 도달했습니다. 그러나 나는 느슨한 결합이라는 생각을 좋아합니다.

런타임 검색은 REST의 성배처럼 보이지만 그러한 클라이언트를 구현하는 방법에 대한 귀중한 논의가 거의 없습니다. 내가 찾은 거의 모든 REST 소스는 개발자 발견을 가정하는 것 같습니다. 누구나 런타임 검색 리소스를 알고 있습니까? 모범 사례? 실제 코드가있는 예제 또는 라이브러리? 한 클라이언트를 위해 PHP (Zend Framework)에서 작업하고 있습니다. 다른 하나는 Objective-C (iOS).

개발자 커뮤니티의 현재 도구 및 지식 세트를 고려할 때 런타임 검색이 현실적인 목표입니까? 모든 URI를 불투명하게 처리하도록 클라이언트를 작성할 수 있지만이를 가장 효율적으로 수행하는 방법은 특히 저 대역폭 연결에서 문제입니다. 어쨌든 URI는 방정식의 일부일뿐입니다. 런타임 컨텍스트에서 링크 템플릿은 어떻습니까? 많은 OPTIONS 요청을하는 것 외에 지원되는 방법을 전달하는 것은 어떻습니까?

이것은 확실히 깨지기 힘든 너트입니다. Google에서는 모든 새로운 API의 기반이되는 Discovery Service를 구현했습니다. TL; DR 버전은 클라이언트가 구문 분석 할 수있는 JSON 스키마와 유사한 사양을 생성하는 것입니다.

그 결과 개발자에게는 더 쉬운 SDK 업그레이드와 더 나은 유지 관리를 의미합니다.

완벽한 솔루션은 아니지만 많은 개발자들이 좋아하는 것 같습니다.

자세한 내용은 링크 를 참조하십시오 (비디오를 시청하십시오).

매혹적인. 당신이 설명하는 것은 기본적으로 HATEOAS 원칙입니다. HATEOAS는 무엇입니까? 이것을 읽으십시오 : http://en.wikipedia.org/wiki/HATEOAS

평신도의 용어로 HATEOAS는 링크 팔로우를 의미합니다. 이 접근 방식은 특정 URL에서 클라이언트를 분리하고 누구도 중단하지 않고 API를 변경할 수있는 유연성을 제공합니다.

집에서 일을했고 그 중심에 도달했습니다. 런타임 검색은 성배입니다. 쫓지 마세요.

UDDI는 런타임 발견에 대한 감동적인 이야기를 들려줍니다 : http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration

API 'RESTful'을 호출하기 전에 충족되어야하는 요구 사항 중 하나는 해당 API 위에 일반 클라이언트 애플리케이션을 작성할 수 있어야한다는 것입니다. 일반 클라이언트를 사용하면 사용자가 모든 API 기능에 액세스 할 수 있어야합니다. 일반 클라이언트는 자원이 미디어 유형에 의해 정의 된 구조를 넘어서는 특정 구조를 가지고 있다고 가정하지 않는 클라이언트 응용 프로그램입니다. 예를 들어 웹 브라우저는 HTML 양식 등을 포함하여 HTML을 해석하는 방법을 알고있는 일반 클라이언트입니다.

이제 웹 상점을위한 HTTP / JSON API가 있고 고객에게 탁월한 사용자 경험을 제공하는 HTML / CSS / JavaScript 클라이언트를 구축하려고한다고 가정합니다. 그 클라이언트를 일반화 하는 것이 현실적인 옵션 일까요? 클라이언트 응용 프로그램 일까요? 아니요. 모든 특정 데이터 요소와 모든 특정 애플리케이션 상태에 대해 특정 룩앤필을 제공하고자합니다. 우리는 API에 이러한 프리젠 테이션 특성에 대한 모든 지식을 포함하고 싶지 않습니다. 반대로 클라이언트는 모양과 느낌을 정의해야하며 API는 데이터 만 전달해야합니다. 이는 클라이언트가 특정 리소스 요소를 특정 레이아웃 및 사용자 상호 작용에 하드 코딩 한 결합을 가지고 있음을 의미합니다.

이것이 HATEOAS의 끝이고 따라서 REST의 끝입니까? 예 그리고 아니오 .

예 , API에 대한 지식을 클라이언트에 하드 코딩하면 HATEOAS의 이점을 잃게됩니다. 서버 측 변경으로 인해 클라이언트가 손상 될 수 있습니다.

아니요 , 두 가지 이유가 있습니다.

1. "RESTful"은 클라이언트가 아닌 API의 속성입니다. 이론상 가능한 한 API의 모든 기능을 제공하는 일반 클라이언트를 빌드 할 수있는 한 API를 RESTful이라고 할 수 있습니다. 클라이언트가 규칙을 따르지 않는다는 사실은 API의 잘못이 아닙니다. 일반 클라이언트의 사용자 경험이 형편 없다는 사실은 문제가되지 않습니다. 실제로 일반 클라이언트가 없는데도 일반 클라이언트를 가질 수 있다는 것을 아는 것이 왜 중요 합니까? 두 번째 이유가 있습니다.
2. RESTful API는 클라이언트에게 원하는 일반적인 방식을 선택할 수있는 옵션을 제공합니다. 훌륭한 사용자 경험을 제공해야하는 클라이언트는 여전히 URI 변경, 기본값 변경 등에 대해 탄력적 일 수 있습니다. 사용자 상호 작용없이 배치 작업을 수행하는 클라이언트는 다른 종류의 변경에 대해 탄력적 일 수 있습니다.

실제 예제에 관심이 있으시면 JAREST 논문을 확인하십시오 . 마지막 섹션은 HATEOAS에 관한 것입니다. JAREST를 사용하면 대화 형이고 시각적으로 매력적인 클라이언트도 100 %는 아니지만 서버 측 변경에 대해 상당히 탄력적 일 수 있음을 알 수 있습니다.

HATEOAS에 대한 중요한 점은 클라이언트 측이 성배라는 것이 아니라 URI 변경으로부터 클라이언트를 분리한다는 점이라고 생각합니다. 시스템이 개체에 대한 링크가 편집 가능한 형식인지 확인합니다. 중요한 점은 하이퍼 미디어를 인식하는 emdia 유형 (예 : HTML, XHTML 등)을 사용하는 것입니다.

당신은 쓰기:

API를 매우 효율적으로 만들려면 쿼리 매개 변수에 대한 많은 링크 템플릿이 필요한 것 같습니다. 이로 인해 대역 외 정보가 다시 들어옵니다.

해당 링크 템플릿이 이전 요청에 제공된 경우 대역 외 정보가 없습니다. 예를 들어 HTML 검색 양식은 링크 템플릿 ( /search?q=%@)을 사용하여 URL ( )을 생성 /search?q=hateoas하지만 클라이언트 (웹 브라우저)는 HTML 양식 및 GET.