REST HATEOAS (성숙도 레벨 3)는 얼마나 유용하고 중요합니까?

일부 고위 팀원들이 REST API가 HATEOAS를 준수하고 모든 Richardson의 성숙도 수준을 구현해야한다고 생각하는 프로젝트에 참여하고 있습니다 ( http://martinfowler.com/articles/richardsonMaturityModel.html )!

AFAIK 대부분의 REST 구현은 HATEOAS를 준수하지 않으며 더 많은 사람들이이를 수행하지 않는 이유가 있어야합니다. 복잡성 추가, 프레임 워크 부족 (서버 및 클라이언트 측), 성능 문제 등의 이유를 생각할 수 있습니다.

어떻게 생각해? 실제 프로젝트에서 HATEOAS에 대한 경험이 있습니까?

REST 커뮤니티의 아무도 REST가 쉽다고 말하지 않습니다. HATEOAS는 REST 아키텍처에 어려움을 더하는 측면 중 하나 일뿐입니다.

사람들은 당신이 제안하는 모든 이유 때문에 HATEOAS를하지 않습니다. 그것은 어렵습니다. 서버 측과 클라이언트 모두에 복잡성을 추가합니다 (실제로 혜택을 받고 싶다면).

그러나 오늘날 수십억 명의 사람들이 REST의 이점을 경험하고 있습니다. 아마존에서 "체크 아웃"URL이 무엇인지 아십니까? 나는하지 않는다. 하지만 매일 체크 아웃 할 수 있습니다. URL이 변경 되었습니까? 몰라, 상관 없어.

신경 쓰는 거 알아? 화면을 작성한 사람은 누구나 Amazon 자동화 클라이언트를 스크랩했습니다. 웹 트래픽을 고심하게 스니핑하고 HTML 페이지 등을 읽고 언제 어떤 페이로드로 어떤 링크를 호출할지 찾는 사람.

그리고 Amazon이 내부 프로세스와 URL 구조를 변경하자마자 링크가 끊어 졌기 때문에 하드 코딩 된 클라이언트가 실패했습니다.

그러나 캐주얼 웹 서퍼들은 거의 문제없이 하루 종일 쇼핑을 할 수있었습니다.

그것은 작동중인 REST이며, 텍스트 기반 인터페이스를 해석하고 직관 할 수 있고, 장바구니로 작은 그래픽을 인식하고, 그것이 실제로 의미하는 바를 파악할 수있는 인간에 의해 증강됩니다.

소프트웨어를 작성하는 대부분의 사람들은 그렇게하지 않습니다. 자동화 된 클라이언트를 작성하는 대부분의 사람들은 신경 쓰지 않습니다. 대부분의 사람들은 처음부터 중단되지 않도록 응용 프로그램을 엔지니어링하는 것보다 중단 될 때 클라이언트를 수정하는 것이 더 쉽다고 생각합니다. 대부분의 사람들은 중요한 곳에 클라이언트가 충분하지 않습니다.

전문 기술 지원이있는 두 시스템과 트래픽 양측의 IT간에 통신하기위한 내부 API를 작성하는 경우, 변경 일정에 따라 변경 사항을 빠르고 안정적으로 전달할 수있는 IT 담당자는 아무것도 구매하지 않습니다. 당신은 그것을 필요로하지 않고, 당신의 앱은 충분히 크지 않으며, 중요 할만큼 오래 지속되지도 않습니다.

사용자 기반이 많은 대규모 사이트에는이 문제가 있습니다. 그들은 시스템과 상호 작용할 때 변덕에 클라이언트 코드를 변경하도록 사람들에게 요청할 수 없습니다. 서버 개발 일정은 클라이언트 개발 일정과 동일하지 않습니다. API의 갑작스러운 변경은 양측의 트래픽과 운영을 방해하기 때문에 관련된 모든 사람에게 허용되지 않습니다.

따라서 이와 같은 작업은 HATEOAS의 이점을 얻을 수 있습니다. 버전이 더 쉽고 이전 클라이언트가 마이그레이션하기 쉽고 이전 버전과의 호환성이 더 쉽습니다.

작업 흐름의 대부분을 서버에 위임하고 결과에 따라 조치를 취하는 클라이언트는 그렇지 않은 클라이언트보다 서버 변경에 훨씬 더 강력합니다.

그러나 대부분의 사람들은 그러한 유연성이 필요하지 않습니다. 그들은 2 개 또는 3 개의 부서를위한 서버 코드를 작성하고 있으며 모두 내부 용입니다. 고장난 경우 고쳐서 정상적인 작동에 반영했습니다.

REST에서든 다른 것에서든 유연성은 복잡성을 증가시킵니다. 간단하고 빠르기를 원하면 유연하게 만드는 것이 아니라 "그냥 해"만하면됩니다. 시스템에 추상화와 역 참조를 추가하면 작업이 점점 더 어려워지고 테스트 할 코드가 많아집니다.

대부분의 REST는 "필요하지 않을 것"이라는 글 머리 기호에 실패합니다. 물론 그렇게 할 때까지.

필요한 경우 사용하고 배치 된대로 사용하십시오. REST는 HTTP를 통해 물건을 앞뒤로 밀지 않습니다. 한 번도 없었고 그보다 훨씬 높은 수준입니다.

그러나 REST가 필요하고 REST를 사용하는 경우 HATEOAS가 필요합니다. 그것은 패키지의 일부이며 그것이 작동하도록 만드는 열쇠입니다.

예, API에서 하이퍼 미디어에 대한 경험이 있습니다. 다음은 몇 가지 이점입니다.

1. 탐색 가능한 API : 사소하게 들릴 수 있지만 탐색 가능한 API의 힘을 과소 평가하지는 않습니다. 데이터를 탐색 할 수있는 기능은 클라이언트 개발자가 API 및 데이터 구조의 멘탈 모델을 훨씬 쉽게 구축 할 수 있도록합니다.

2. 인라인 문서 : URL을 링크 관계로 사용하면 클라이언트 개발자가 문서로 이동할 수 있습니다.

3. 간단한 클라이언트 논리 : URL을 직접 구성하는 대신 단순히 따르는 클라이언트는 구현 및 유지 관리가 더 쉬워야합니다.

4. 서버는 URL 구조의 소유권을 갖습니다. 하이퍼 미디어를 사용하면 서버에서 사용하는 URL 구조에 대한 클라이언트의 하드 코딩 된 지식이 제거됩니다.

5. 콘텐츠를 다른 서비스로 오프로드 : 콘텐츠를 다른 서버 (예 : CDN)로 오프로드 할 때 하이퍼 미디어가 필요합니다.

6. 링크를 통한 버전 관리 : Hypermedia는 API 버전 관리를 지원합니다.

7. 동일한 서비스 / API의 다중 구현 : 하이퍼 미디어는 동일한 서비스 / API의 다중 구현이 존재할 때 필요합니다. 예를 들어 서비스는 게시물과 댓글을 추가하기위한 리소스가있는 블로그 API 일 수 있습니다. 서비스가 하드 코딩 된 URL 대신 링크 관계로 지정되면 동일한 서비스가 다른 URL에서 여러 번 인스턴스화되고 다른 회사에서 호스팅하지만 하나의 단일 클라이언트가 동일한 잘 정의 된 링크 세트를 통해 액세스 할 수 있습니다.

이 글 머리 기호에 대한 자세한 설명은 http://soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html 에서 확인할 수 있습니다 .

(비슷한 질문이 여기에 있습니다 : /software/149124/what-is-the-benefit-of-hypermedia-hateoas 나도 같은 설명을 준 경우)

Richardson의 성숙도 레벨 3은 가치가 있으며 채택되어야합니다. Jørn Wildt는 이미 몇 가지 장점을 요약했으며 Wilt의 다른 답변은이를 매우 잘 보완합니다.

그러나 Richardson의 성숙도 레벨 3은 Fielding의 HATEOAS와 동일하지 않습니다. Richardson의 성숙도 레벨 3은 API 디자인에 관한 것입니다. Fielding의 HATEOAS는 API 디자인에 관한 것이기도하지만, 클라이언트 소프트웨어 는 리소스가 미디어 유형에 의해 정의 된 구조를 넘어서는 특정 구조를 가지고 있다고 가정해서는 안됩니다. 이를 위해서는 특정 웹 사이트에 대한 지식이없는 웹 브라우저와 같은 매우 일반적인 클라이언트가 필요합니다. Roy Fielding이 REST라는 용어를 만들고 REST 준수를위한 요구 사항으로 HATEOAS를 설정했기 때문에 문제는 HATEOAS를 채택하고 싶지만 그렇지 않은 경우에도 여전히 API RESTful을 호출 할 수 있습니까? 나는 우리가 할 수 있다고 생각한다. 설명하겠습니다.

우리가 HATEOAS를 달성했다고 가정합니다. 응용 프로그램의 클라이언트 측은 이제 매우 일반적이지만 리소스의 의미에 대한 지식이 없으면 리소스의 표현이 이러한 의미를 반영하도록 조정할 수 없기 때문에 사용자 경험이 나쁠 가능성이 높습니다. 리소스 'car'와 리소스 'house'가 동일한 미디어 유형 (예 : application / json)을 갖는 경우 속성 테이블 (이름 / 값 쌍)과 같이 동일한 방식으로 사용자에게 표시됩니다.

하지만 우리 API는 정말 RESTful입니다.

이제이 API 위에 두 번째 클라이언트 애플리케이션을 빌드한다고 가정합니다. 이 두 번째 클라이언트는 HATEOAS 아이디어를 위반하고 리소스에 대한 하드 코딩 된 정보를 가지고 있습니다. 자동차와 집을 다른 방식으로 표시합니다.

API를 여전히 RESTful이라고 할 수 있습니까? 나도 그렇게 생각해. 클라이언트 중 하나가 HATEOAS를 위반 한 것은 API의 잘못이 아닙니다.

나는 편안하고 API를, 일반적인 클라이언트가 구현 될 수있는, 즉 API를 구축 조언 이론을 하지만, 대부분의 경우에, 당신은 필요 일부 사용성 요구 사항을 충족하기 위해 클라이언트에서 리소스에 대한 하드 코딩 된 정보를. 그래도 클라이언트와 서버 간의 종속성을 줄이기 위해 가능한 한 적은 하드 코딩을 시도하십시오.

나는라는 내 REST 구현 패턴 HATEOAS에 대한 섹션이 포함되어 있습니다 JAREST을 .

응답이 HAL-Json에있는 REST 레벨 3 API를 구축하고 있습니다. HATEOAS는 프런트 엔드와 백 엔드 모두에 적합하지만 도전이 따릅니다. HAL-Json 응답 내에서 ACL을 관리하기 위해 몇 가지 사용자 지정 / 추가 작업을 수행했습니다 (HAL-Json 표준을 위반하지 않음).

내가 본 HATEOAS의 가장 큰 장점은 프런트 엔드 응용 프로그램에서 URL을 작성 / 추측 할 필요가 없다는 것입니다. 필요한 것은 진입 점 ( https://hostname) 뿐이며 여기에서 응답에 제공된 링크 또는 템플릿 링크를 사용하여 리소스를 탐색 할 수 있습니다. 버전 관리는 쉽게 처리 할 수 ​​있으며 URL의 이름을 바꾸거나 바꾸고 프런트 엔드 코드를 손상시키지 않고 추가 관계로 리소스를 확장 할 수 있습니다.

프런트 엔드의 리소스 캐싱은 셀프 링크를 사용하는 케이크 조각입니다. 또한 소켓 연결을 통해 리소스를 클라이언트에 푸시합니다. 리소스도 HAL로 렌더링되므로 동일한 방식으로 캐시에 쉽게 추가 할 수 있습니다.

HAL-Json 사용의 또 다른 장점은 따라야 할 문서화 된 표준이 있기 때문에 응답 모델이 어떻게 생겼는지 명확하다는 것입니다.

우리의 사용자 정의 중 하나는이 작업을 자동 링크 개체 내부 객체 첨가 있다는 것을 인증 된 사용자는 해당 리소스에서 수행 할 수있는 액션 또는 CRUD 조작 선단부에 노출하는 ( create:POST, read:GET, update:PUT, edit:PATCH, delete:DELETE). 이와 같이 프런트 엔드 ACL은 REST API 응답에 의해 전적으로 결정되며이 책임을 백 엔드 모델로 완전히 이동합니다.

따라서 간단한 예제를 제공하기 위해 다음과 같은 HAL-Json에 게시 객체를 가질 수 있습니다.

{
    "_links": {
        "self": {
            "href": "https://hostname/api/v1/posts/1",
            "actions": {
                "read": "GET",
                "update": "PUT",
                "delete": "DELETE"
            }
        }
    },
    "_embedded": {
        "owner": {
            "id": 1,
            "name": "John Doe",
            "email": "john.doe@example.com",
            "_links": {
                "self": {
                    "href": "https://hostname/api/v1/users/1",
                    "actions": {
                        "read": "GET"
                    }
                }
            }
        }
    },
    "subject": "Post subject",
    "body": "Post message body"
}

이제 프런트 엔드 에서 수행 할 작업은 수행하려는 작업이 작업 개체에 있는지 확인 AclService하는 isAllowed메서드로를 빌드하는 것 입니다 .

현재 프런트 엔드에서는 다음과 같이 간단 해 보입니다. post.isAllowed('delete');

REST 레벨 3은 훌륭하다고 생각하지만 두통이 생길 수 있습니다. REST에 대해 잘 이해하고 있어야하며, 레벨 3 REST로 작업하려면 REST 개념을 엄격하게 따르는 것이 좋습니다. 그렇지 않으면 구현할 때 쉽게 길을 잃을 수 있습니다.

우리의 경우 프런트 엔드와 백 엔드를 모두 구축한다는 이점이 있지만 원칙적으로 차이가 없어야합니다. 그러나 제가 우리 팀에서 본 일반적인 함정은 일부 개발자가 백엔드 모델을 변경하여 프론트 엔드 요구에 "적합"하도록 변경하여 프론트 엔드 문제 (아키텍처)를 해결하려고한다는 것입니다.

일부 실제 프로젝트에서 HATEOAS를 사용했지만 Richardson과는 다른 해석이 있습니다. 그것이 당신의 상사가 원하는 것이라면, 나는 당신이 그것을해야한다고 생각합니다. HATEOAS는 리소스에 HTML 문서 유형, 관련 리소스에 대한 하이퍼 링크 및 GET 이외의 동사에 대한 기능을 노출하는 HTML 양식이 포함되어야 함을 의미합니다. (이것은 Accept 유형이 text / html 일 때입니다. 다른 콘텐츠 유형은 이러한 추가 항목이 필요하지 않습니다.) 전체 애플리케이션의 모든 REST 리소스를 함께 연결해야한다는 믿음이 어디서 왔는지 모르겠습니다. 네트워크 응용 프로그램에는 직접 관련되거나 관련되지 않은 여러 리소스가 포함되어야합니다. 또는 XML, JSON 및 기타 유형이이를 따라야한다고 믿는 이유. (HATEOAS는 HTML 전용입니다.)