RESTful API에서 링크 확장 관계 유형 URI가 가리키는 대상은 무엇입니까?

Question

저는 최근에 RESTful 일 필요가있는 API를 설계 해 왔으며 HTTP 헤더와 쿼리 문자열 매개 변수를 독점적으로 사용하여 메타 데이터를 정의하여 응답 본문을 실제 리소스 데이터로 자유롭게 사용할 수 있도록 시스템을 정의했습니다. 만.

그러나 지금은 HATEOAS에 대한 링크를 생각하고 있으며 HTTP 헤더 또는 쿼리 문자열 매개 변수의 모든 내용을 유지하기 위해 HTTP Link 헤더 필드를 사용하기로 결정했습니다.

이것은 직접 응답을 찾는 데 어려움이있는 rel 속성에 대한 질문을 제기했습니다.

내 생각은 자원의 수집에 대한 응답으로 전송됩니다 Link들 중 하나가 같을 것입니다 : 이것은 클라이언트가 간단한 문자열 확장을 사용할 수 있도록 할 Link: <https://api.domain.com/things/{id}>; rel="..."

을 RFC6570에 정의 된 바와 같이, 메타 데이터를 각 리소스에 임베드하지 않고 클라이언트가 URI 템플릿 및 리소스 ID 이외의 것을 알 필요없이 컬렉션의 각 리소스에 대한 올바른 리소스 URI를 만들 수 있습니다.

그러나 여기서는 rel이 무엇인지, 무엇을 가리켜 야하는지 확실하지 않습니다.

URI가 관계 유형의 의미, 클라이언트가 SHOULD의 정의를 포함하는 자원을 가리킬 수 있지만 : RFC5988에서

, 그것은 확장 관계의 유형은 URI하고해야한다고 말한다 서버에 과부하가 걸리지 않도록 해당 리소스에 자동으로 액세스하지 않습니다.

제 질문은 RESTful API에서 정의가 어떻게되어야할까요?

외모로 보니 나는 단지 rel 같은 것을 https://api.domain.com/media/thing 또는 그와 비슷한 것으로 만들 수 있습니다.

하지만 실제로 정의 된 내용은 무엇입니까?

기술적으로는 아무 것도 될 수없는 것처럼 보입니다. 예를 들어 간단한 설명이있는 일반 텍스트 문서입니다.

이러한 종류의 rel 속성에 대한 RESTful 표준이 있으며 무엇을 나타내야합니까?

도움을 주시면 감사하겠습니다.

Answer 1

레벨 Richardson's Maturity Model을 보면 rel은 게시 된 링크/관계의 이름을 나타내는 것으로 보입니다. 귀하의 경우 예를 들어 curie:thing-by-id (제안 된 HAL draft에서 제안 된 것처럼 큐를 사용한다고 가정)으로 번역 될 수 있습니다. 아이디어는 클라이언트가 실제로 url을 들여다 보지 않고 이름 (rel)으로 링크를 검색 할 수 있다는 것입니다.