REST와 HATEOAS는 웹 서비스를위한 훌륭한 아키텍처입니까?

내가 올바르게 이해하면 REST는 Roy Fielding 에 의해 웹 아키텍처의 설명 모델 로 공식화되었습니다 . AFAIK Fielding은 REST가 좋지 않다고 주장했지만 웹의 사실상 아키텍처를 설명했습니다. 이 시점에서 웹은 이미 엄청난 성공을 거둔 분산 하이퍼 텍스트 시스템으로 입증되었으므로 이러한 종류의 REST는 주로 사람이 탐색하고 사용하는 분산 하이퍼 미디어 영역의 성공적인 아키텍처로 REST를 검증합니다.

REST 웹 서비스는 REST 아키텍처를 API에 적용하여 작성되었습니다. 그러나 실제로 REST가이 도메인에 바람직한 아키텍처라고 생각할 이유가 있습니까? 더 구체적으로, HATEOAS가 기계 간 통신에 유리한 설계 원칙이라는 증거가 있습니까?

내 관심사는 HATEOAS가 잘 알려진 컨텐츠 유형 (HTML, 이미지, 비디오 등)이 거의없고 클라이언트가이를 소비하는 방법을 알고 있기 때문에 하이퍼 미디어에 적합하다는 것입니다. 그러나 API의 경우 컨텐츠 유형은 매우 구체적이며 클라이언트가 특별히 소비하도록 프로그래밍 된 경우에만 클라이언트가 의미있는 방식으로 소비 할 수 있습니다. 클라이언트에게 URL을 반환한다고해서 클라이언트가 표시된 리소스를 사용할 수있는 것은 아닙니다.

AFAIK Fielding은 REST가 좋지 않다고 주장했지만 웹의 사실상 아키텍처를 설명했습니다.

나는 그것을 조금 팔았다 고 생각합니다. REST는 결국 Fielding 이 HTTP / 1.1 spec 의 수석 아키텍트 로 사용 했던 아키텍처 스타일 의 열거입니다 .

그러나 실제로 REST가이 도메인에 바람직한 아키텍처라고 생각할 이유가 있습니까? HATEOAS가 기계 간 통신에 유리한 설계 원칙이라는 증거가 있습니까?

"때에 따라 다르지". HATEOAS는 REST 의 균일 한 인터페이스 제약 조건의 일부입니다 .

소프트웨어 엔지니어링 일반 원리를 컴포넌트 인터페이스에 적용함으로써 전체 시스템 아키텍처가 단순화되고 상호 작용의 가시성이 향상됩니다. 구현은 제공하는 서비스와 분리되어 독립적 인 발전 가능성을 장려합니다. 그러나 정보가 응용 프로그램의 요구에 맞는 형식이 아닌 표준화 된 형식으로 전송되기 때문에 균일 한 인터페이스가 효율성을 저하 시킨다는 단점이 있습니다. REST 인터페이스는 웹의 일반적인 경우를 최적화하면서 대규모의 하이퍼 미디어 데이터 전송에 효율적으로 설계되었지만 다른 형태의 아키텍처 상호 작용에는 최적의 인터페이스가 아닙니다.

이것이 무엇을 의미하는지 잠시 생각해 봅시다. 무선 라우터에 문제가있을 때 stackexchange에 응답을 제출할 때 사용하는 것과 동일한 브라우저를 사용하여 통신 할 수 있습니다. 특히, 어떤 브라우저를 사용하고 있는지 또는 브라우저가 라우터가 기대하는 것보다 몇 배나 앞서 있는지 여부는 중요하지 않습니다. 브라우저를 작성한 엔지니어링 조직이 라우터 인터페이스를 작성한 조직과 완전히 독립적 인 것은 중요하지 않습니다.

그것은 바로 작동합니다 .

물론 보편적 인 것은 아닙니다. Fielding은 2008 년 에 다음과 같이 썼습니다.

그렇다고 모든 사람들이 REST 아키텍처 스타일에 따라 자신의 시스템을 설계해야한다고 생각하지는 않습니다. REST는 여러 조직에 걸친 오래 지속되는 네트워크 기반 애플리케이션을위한 것입니다. 제약 조건이 필요하지 않으면 사용하지 마십시오.

REST 아키텍처 스타일을 형성하는 구속 조건은 유도하는 특성에 대해 선택되었습니다. 이러한 속성이 사용 사례에 중요하지 않은 경우 해당 제약 조건을 삭제하는 것을 절대적으로 고려해야합니다.

기계 대 기계가 어려워지는 부분은 인간이 표현에 의해 제공된 의미와 일치하는 퍼지 능력을 상실한 것입니다. 클라이언트는 미디어 유형 만 알면 얻을 수 있지만 일반적으로 의미를 도출하기 위해 의미 적 신호를 보는 인간이 있습니다.

schema.org 는 기계가 읽을 수있는 어휘를 만들기위한 노력의 일부입니다. 기계 에이전트는 클라이언트를 사용하여 시맨틱 힌트를 찾고 의미에 대한 자체 이해를 적용하여 올바른 조치를 선택합니다.

그러나 그것은 일이다. 고객이 기계 친화적 인 표현을 개발하고 해당 표현이 앞뒤로 호환되도록하여 클라이언트를 독립적으로 개발할 수 있도록하는 데 투자해야합니다.

단일 조직이 클라이언트와 서버를 모두 제어 할 때이 독립성의 이점은 훨씬 작으므로 제약 조건이 적절한 아키텍처 선택이 아닐 수 있습니다.

아니요, '전체 REST'는 그렇게 크지 않습니다.

API에서 HATEOS를 구현하는 사람들이 부족하고 특정 호출에 사용할 HTTP 동사에 대한 끝없는 인수로 입증됩니다.

그러나 왜 REST가 그렇게 인기가 있는지 인식해야합니다. 채택하기 전에 승인, 시간 초과, 대화 ID 및 상태와 관련된 ebXML 및 SOAP와 같은 여러 가지 복잡한 복잡한 프로토콜이있었습니다.

이러한 것들을 준비하고 실행 한 다음 API 소비자에게 설명 하는 것은 어려운 일이었습니다. "쿼리 문자열에서 원하는 ID로 GET을 수행하고 데이터를 보내지 않는 이유는 무엇입니까?" 명백하고 일반적인 질문이었습니다.

그런 다음 두 번째 문제는 XML이며, 자바 스크립트는 그것을 이해하지 못했습니다. 스키마는 엉덩이에 통증이 있었고 주로 txt 파일로 구성 <MyLongObjectName>됩니다. 그래서 사람들은 대신 JSON을 사용하기 시작했습니다.

이제 REST는 그 주위에 약간의 컬트가 있지만 규칙이 모호하기 때문에 소비자가 '그냥 가져 가서'6 개월 동안 탑승하지 않고 사용할 수있는 간단한 API를 사용하는 것을 막을 수는 없습니다. 방법.

Roy는 REST의 대부분의 원칙을 처음으로 발명 한 사람이 아니며 다양한 특정 문제를 해결하기 위해 이전 시스템에서 작동하는 것으로 알려진 많은 원칙을 모았습니다. REST는 이러한 원칙을 단일 아키텍처에 적용한 자연스러운 결론입니다.

Roy Fielding이 REST 에 대한 논문을 쓰기 전에도 HTTP는 이미 REST로 알려진 원칙을 중심으로 설계되었습니다. 그의 논문 의 결론 에서 그는 다음과 같이 썼다.

인터넷 엔지니어링 태스크 포스 내에서 기존 하이퍼 텍스트 전송 프로토콜 (HTTP / 1.0) [19]을 정의하고 새로운 표준 인 HTTP / 1.1 [42] 및 URI (Uniform Resource Identifiers) [21]에 대한 확장을 설계하기위한 노력의 시작 [21] ], 나는 월드 와이드 웹의 작동 방식에 대한 모델이 필요하다는 것을 인식했습니다. REST (Representational State Transfer) 아키텍처 스타일이라고하는 전체 웹 응용 프로그램 내에서의 이상적인 상호 작용 모델은 최신 웹 아키텍처의 기초 가되어 기존 아키텍처의 결함을 식별하고 확장 할 수있는 기본 원칙을 제공합니다. 배포 전에 검증되었습니다 .

REST 및 HATEOS는 다음과 같이 설계된 문제에 적합합니다.

REST는 대기 시간 및 네트워크 통신 을 최소화하면서 동시에 구성 요소 구현의 독립성 및 확장 성을 최대화 하는 조정 된 아키텍처 제약 조건 세트입니다 . 이것은 다른 스타일이 컴포넌트 시맨틱에 중점을 둔 커넥터 시맨틱에 제한을 두어 달성됩니다. REST는 상호 작용 의 캐싱 및 재사용, 구성 요소의 동적 대체 가능성 및 중개자 에 의한 조치 처리를 가능하게하여 인터넷 규모의 분산 하이퍼 미디어 시스템의 요구를 충족시킵니다.

그러나 웹 및 REST가 모든 문제에 반드시 적합한 것은 아니라는 점에 유의해야합니다.

마찬가지로 제안 된 확장을 REST와 비교하여 확장이 아키텍처에 맞는지 확인할 수 있습니다. 그렇지 않은 경우 해당 기능을보다 적합한 아키텍처 스타일과 병렬로 실행중인 시스템으로 리디렉션하는 것이 더 효율적입니다.

따라서 귀하의 질문이 "RESA 및 HATEOAS가 웹 서비스에 적합한 아키텍처입니까?" 그렇다면 대답은 단순히 "예, 웹 서비스를위한 훌륭한 아키텍처입니다"입니다. 문제는 실제로 사람들이 웹 제약 조건에 맞게 수정하여 해결하려는 모든 문제가 처음부터 웹 서비스 였어야하는지 여부입니다.

실제로 REST에 맞지 않는 많은 API가 있습니다. REST가 해결하기 위해 설계된 일종의 확장 성을 필요로하지 않는 API는 독립적으로 발전 할 수 있고 오래 지속될 필요가없는 여러 조직에서 사용하지 않습니다. 이러한 문제의 경우 REST 제약 조건은 구속복 일뿐입니다.

그러나 실제로 REST가이 도메인에 바람직한 아키텍처라고 생각할 이유가 있습니까? 보다 구체적으로, HATEOAS가 기계 간 통신에 유리한 설계 원칙이라는 증거가 있습니까?

많은 사람들의 문제를 해결하는 데있어 웹의 성공이 증거입니다. REST는 많은 이전 아키텍처 스타일의 디자인을 결합한 하이브리드 아키텍처입니다. 많은 문제 도메인에는 웹의 모든 요구 사항이 없으며 REST의 모든 제약 조건을 준수 할 필요가 없습니다. 그렇기 때문에 REST의 일부만 적용하고 나머지는 적용하지 않고 제대로 작동하는 많은 성공적인 아키텍처가있는 이유입니다. 예를 들어, HATEOAS 및 Uniform Interface는 상대적으로 사용 중단 기간이 비교적 짧은 조직 경계와 시스템을 넘을 필요가없는 API에서 종종 건너 뛰는 원칙입니다.

Adobe Experience Manager에 대한 Fielding 프레젠테이션 :

REST는 아키텍처가 아닙니다!

Rest는 인터넷에 존재하는 다른 아키텍처를 추상화 한 아키텍처 스타일입니다.

REST는 아키텍처 속성을 유도하기위한 디자인 제약의 누적입니다.

REST는 유행어이며 모두가 RESTful API를 원합니다. 실제로 사람들이 REST 제약 조건에 직면했을 때 모든 제약 조건을 적용 할 때 얻을 필요가 없거나 이익이 없기 때문에 이러한 제약 조건 중 일부를 삭제했습니다.

언급했듯이 HATEOAS는 클라이언트가 웹 브라우저 일 때 유용합니다. 클라이언트가 모바일 앱인 경우에는 그리 많지 않을 수 있습니다. 모범 사례가 될 수 있지만 모바일 앱 팀과 백엔드 팀이 그러한 제약을 철폐하기로 동의 할 정도로 애플리케이션 설계와 관련된 비용도 많이 있습니다. 두 팀이 같은 회사에서 일하기 때문에 느슨하게 연결되어 있지 않기 때문에 이런 종류의 의미가 있습니다.

AEM의 REST

다른 서버에서 사용하는 서비스를 작성하려는 경우 xmlrpc가 올바른 선택입니다. 개방형 인터넷을 통해 씬 클라이언트 또는 저전력 장치 또는 알 수없는 클라이언트가 서비스를 사용하려는 경우 json을 사용하여 휴식을 고려하십시오. 그러나 json은 xml과 비교할 때 일반 데이터를 지정하는 데 열등한 표기법입니다.