HATEOAS를 준수합니까? 서로 다른 결과를 가진 동일한 주소 얻기

Question

이 호출이 매번 다른 리소스를 반환 할 때 GET /resources을 통해 리소스를 노출하려면 HATEOAS 호환입니까?

예를 들어 일부 내부 알고리즘에 따라 클라이언트간에 자원을 배포하는 경우 모든 클라이언트가 항상 동일한 리소스를 수신하는 것을 원하지 않습니다 (즉, '오늘의 구문'을 코딩하여 무작위로 배포한다고 가정 해 봅시다) :

는

먼저 호출 : GET/자원

는

200 OK 
{ 
    "_links" : { "self" : "/resources/1" }, 
    "data" : "foo" 
} 

는

두 번째 전화 : GET/자원

200 OK 
{ 
    "_links" : { "self" : "/resources/2" }, 
    "data" : "bar" 
} 

또는이다 더 나은 0을 제공하는links 개체를 콘크리트 리소스로 반환하고 두 번째 호출을합니까?

Answer 1

HATEOAS에 대한 링크는 다음과 같습니다. 따라서 API 루트를 제외하고 이러한 작업을 메타 데이터 (예 : "self")와 같은 링크로 노출 할 때까지는 HATEOAS 제약 조건을 충족합니다. URI 구조에 대한 표준은 없으며 제안 만 있습니다. 예를 들어 명명 된 리소스에 대한 호출을 라우팅하는 것이 더 쉽습니다. REST 클라이언트의 경우 URI 구조는 링크 메타 데이터를 검사하여 링크를 따라 가는지 여부를 결정하기 때문에 중요하지 않습니다.

현재 예제에서 /resources에는 자체 설명 메타 데이터가 있어야합니다 (예 : rel=chooser). 그래서 고객은 그것이 무엇인지 알게 될 것입니다. 경로가 URI의 계층 적 부분을 설명하기 때문에 URI 구조가 URI 표준을 위반한다고 생각하지만 현재의 경우 /resources과 /resources/1, /resources/2 개의 URI 사이에 계층 구조가 없습니다. 따라서 "선택기"라는 단어를 선택하거나 별칭을 만들거나 별칭을 지정하려면 /resources/chooser 또는 /resources?chooser=true을 사용하는 것이 좋습니다.

Answer 2

직접 질문에 답하기 위해/resource가 응용 프로그램의 진입 점이라고 가정하거나/resource에 링크하는 루트 리소스가 있으면 HATEOAS 제약 조건을 확실히 충족시킵니다.

이것이 RESTful 아키텍처인지 여부는 약간 까다 롭습니다. 한 가지는 절대 결과가 캐시 할 수 없음을 나타내야한다는 것입니다. HTTP를 사용하면 HTTP 헤더와 함께 사용됩니다. 그것은/resource에 대한 모든 요청이 새로운 리소스를 얻게된다고 가정합니다. 아마도 같은 사용자가 동일한 리소스를 얻습니다. 캐싱을 허용 할 수 있습니다.

저는 항상 GET의 멱등수에 대해 혼란스러워합니다. GET을 사용하여 검색 할 수 있으며, GET을 사용하여 결과를 변경할 수도 있습니다. 물론 그것은 국가를 변화시키는 다른 것입니다 ...하지만 나는 그들이 결과의 클릭 스루 (clickthroughs)에 기반한 순위를 바꿀 것이라고 읽었습니다. 그것은 또한 GET입니다 ... 그래서 ??

내 API이고 요청을 POST로만 만드는 것은 그리 큰 문제가 아니었던 것 같습니다. 아마도 POST와 함께 406을 얻을 수있었습니다. 내가 정말로 필요하다면 나는 그것에 대해 너무 많이 걱정하지 않을 것이다.