IT story

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

hot-time 2020. 9. 4. 08:08
반응형

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 에서 찾을 수 있습니다 .

(여기에 비슷한 질문이 있습니다 : https://softwareengineering.stackexchange.com/questions/149124/what-is-the-benefit-of-hypermedia-hateoas 여기서 동일한 설명을했습니다)


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

However, Richardson's maturity level 3 is not the same as Fielding's HATEOAS. Richardson's maturity level 3 is only about API design. Fielding's HATEOAS is about API design too, but also prescribes that the client software should not assume that a resource has a specific structure beyond the structure that is defined by the media type. This requires a very generic client, like a web browser, which doesn't have knowledge about specific websites. Since Roy Fielding has coined the term REST and has set HATEOAS as a requirement for compliance to REST, the question is: do we want to adopt HATEOAS and if not, can we still call our API RESTful or not? I think we can. Let me explain.

Suppose we have achieved HATEOAS. The client-side of the application is now very generic, but most likely, the user experience is bad, because without any knowledge of the semantics of the resources, the presentation of the resources cannot be tailored to reflect those semantics. If resource 'car' and resource 'house' have the same media type (e.g. application/json), then they will be presented to the user in the same way, for example as a table of properties (name/value pairs).

But okay, our API is really RESTful.

Now, suppose we build a second client application on top of this API. This second client violates the HATEOAS ideas and has hard-coded information about the resources. It displays a car and a house in different ways.

Can the API still be called RESTful? I think so. It is not the API's fault that one of its clients has violated HATEOAS.

I advise to build RESTful APIs, i.e. APIs for which a generic client can be implemented in theory, but in most cases, you need some hard-coded information about resources in your client in order to satisfy the usability requirements. Still, try to hard-code as little as possible, to reduce the dependencies between client and server.

I have included a section on HATEOAS in my REST implementation pattern called JAREST.


We are building a REST level 3 API where our response is in HAL-Json. HATEOAS is great for both front and back-end but it comes with challenges. We made some customizations/additions for also managing ACL inside the HAL-Json response (which doesn't break the HAL-Json standard).

The biggest advantages to HATEOAS I see is that we do not need to write/guess any urls on our front-end application. All you need is a entry point (https://hostname) and from there on you can just browse your way through the resources using the links or templated links provided inside the response. Like that versioning can be handled easily, renaming/replacing urls, extending resources with additional relations without breaking front-end code.

Caching of resources on front-end is a piece of cake using the self links. We also push resources to clients through a socket connection, since those are also rendered in HAL we could easily add them to cache the same way.

Another advantage of using HAL-Json is that it is clear what the response model should look like, since there is a documented standard that should be followed.

One of our customizations is that we added an actions object inside the self-link object that exposes to the front end which actions or CRUD operations the authenticated user is allowed to perform on the respective resource (create:POST, read:GET, update:PUT, edit:PATCH, delete:DELETE). Like this our front end ACL is totally dictated by our REST API response, moving this responsibility fully to the the back-end model.

So to give a quick example you could have a post object in HAL-Json that looks something like this:

{
    "_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"
}

Now all we have to do on front end is build a AclService with an isAllowed method that checks whether the action we want to perform is in the actions object.

Currently on front-end it looks as simple as: post.isAllowed('delete');

I think REST level 3 is great, but it can lead to some headaches. You will need to have a great understanding of REST and if you want to work with level 3 REST I would suggest to follow the REST concept strictly otherwise you will easily get lost on your way when implementing it.

In our case we have the advantage that we are building both front and back-end but in principle it should NOT make a difference. But a common pitfall I have seen in our team is that some developers try to solve front-end issues (architecture) by changing their back-end model so it "suits" the front-end needs.


I have used HATEOAS in some real projects, but with a different interpretation than Richardson. If that is what your bosses want, then I guess you should just do it. I take HATEOAS to mean that your resources should include an HTML doctype, hyperlinks to related resources and HTML forms to expose functionality for verbs other than GET. (This is when the Accept type is text/html - other content types don't require these extras.) I don't know where the belief that all REST resources in your entire application have to be glued together came from. A network application should contain multiple resources that may or may not be directly related. Or why it is believed that XML, JSON and other types need to follow this. (HATEOAS is HTML-specific.)

참고URL : https://stackoverflow.com/questions/20335967/how-useful-important-is-rest-hateoas-maturity-level-3

반응형