HATEOAS 하이퍼 미디어의 런타임 검색?

Question

HATEOAS는 응답 (HAL, JSON-LD 등)으로 응용 프로그램 내에서 해당 시점에 수행 할 수있는 모든 작업을 보내어 응용 프로그램 상태를 나타냄을 이해합니다.

예를 들어 은행의 계정 리소스를 보면 계정을 입금하거나 인출하거나 폐쇄 할 수 있습니다 (OPTIONS는 UPDATE 및 DELETE 동사를 반환 할 수 있음).

이러한 링크 (소비 클라이언트에 의한)의 런타임 검색 가능성 측면에서 어떻게 이러한 문제를 해결할 수 있습니까?

이러한 링크를 보내려는 목적이 클라이언트를 서버에서 분리하고 응답에서 하이퍼 미디어로 상태를 구동하는 것이라면 개발자가 의미를 갖기 위해 개발자가 응용 프로그램에 하드 코드해야하는 지식이 있어야합니다 반환되는 응답의

OPTIONS 요청을 보내는 것이 리소스의 현재 상태와 다음에 할 수있는 작업을 결정하는 방법이지만 실제로 사용할 URI를 찾기 위해 COOL URI로 하드 코드 된 것입니까?

Answer 1

표현적이고 발견 가능한 하이퍼 미디어를 만들려고 노력하는 데있어 선행 기술이 많이 있습니다. 당신은 검토 할 수 있습니다

http://www.markus-lanthaler.com/hydra/

• http://json-ld.org/
내가 어쩌면 특정 속성이 상태를 결정하거나 어쩌면 문을 전환하는 검사 if 문 시리즈를 생각하고있다. 이것은 올바른 경로입니까? 아니면 하이퍼 미디어 검색의 더 나은 방법이 있습니까?

현재 나의 생각은 당신이 협상하고 프로토콜을 따라 당신의 생각을 더욱 구체화하고 싶다는 것입니다; if 문보다는 상태 기계를 생각하십시오.

처음에는 How To GET a Cup of Coffee을 검토하십시오.

RESTBucks가 제공하는 문서의 하이퍼 링크는 클라이언트가 RESTBucks 프로토콜 협상을 지원하도록 설계되었습니다. 클라이언트가 이미 그 프로토콜이 모델로 구워 졌음을 이미 알고 있다고 가정합니다. 다시 말해 클라이언트는 프로토콜 협상을 통해 goal에 도달 할 수 있음을 이미 이해하고 있습니다.

물론 동일한 목표를 달성하는 여러 프로토콜이있을 수 있습니다. 예를 들어 RESTBucks는 "Give Away Day Old Coffee"프로토콜도 지원할 수 있습니다. 각각의 존재를 발표하면 클라이언트는 목표 중 더 나은 표현을 선택하고 그 경로를 따라야합니다.

Answer 2

@VoicesOfUnreason과 마찬가지로 HATEOAS URI는 변경할 수 있도록 URI가 검색 가능하고 문서화되지 않았습니다. 즉, 시스템에 들어가는 진입 점이 아니면 (클라이언트에 의해 하드 코딩 될 수있는 유일한 것임) Cool URIs - 나머지 부분을 진화시키는 기능을 원한다면 너무 많이 사용해서는 안됩니다. 미래의 시스템의 URI 구조. 실제로 이것은 useful의 REST 기능 중 가장 큰 기능 중 하나입니다.

나머지 비 Cool URI는 시간이 지남에 따라 변경 될 수 있으며 API 설명서는 하이퍼 미디어 순회를 통해 런타임에 발견되어야한다는 사실을 설명해야합니다.

Richardson's Maturity Model (level 3)에서 보면 링크가 작동하는 위치가됩니다. 예를 들어 최상위 레벨 인/api/version (/ 1)에서 그룹에 대한 링크가 있음을 알 수 있습니다.

루트 : 여기이 HAL Browser 같은 도구에서 볼 수있는 방법은 추가 기능은 단순히 엔드 포인트에 POST 것

{ 
    "_links": { 
    "self": { 
     "href": "/api/root" 
    }, 
    "api:group-add": { 
     "href": "http://apiname:port/api/group" 
    }, 
    "api:group-search": { 
     "href": "http://apiname:port/api/group?pageNumber={pageNumber}&pageSize={pageSize}&sort={sort}" 
    }, 
    "api:group-by-id": { 
     "href": "http://apiname:port/api/group/id" (OR "href": "http://apiname:port/api/group?id={id}") 
    } 
    } 
} 

, 다음은 2 개 GET 방법이있을 것이다. 여기

{ 
    "Id" : 123, 
    "Name" : "test", 
    "_links": { 
    "self": { 
     "href": "/api/group/1" (OR "/api/group?id=1") 
    }, 
    "edit": { 
     "href": "http://apiname:port/api/group/1" 
    }, 
    "api:delete": { 
     "href": "http://apiname:port/api/group/1" 
    }, 
    "api:items-query": { 
     "href": "http://apiname:port/api/bonus?groupId=1" 
    } 
    } 
} 

, 편집이 것 : 특정 그룹 (예를 들어 # 123)로 드릴 다운하면 다음

{ 
    "groups": [ 
     { 
     "id": 123, 
     "name": "Test Group" 
     }, 
     { 
     "id": 134, 
     "name": "Tennis squad" 
     } 
    ] 
} 

: 이런 식으로 뭔가를 반환 할 수

GET /api/group?pageNumber=0&pageSize=20&sort=asc

단순히 PUT이어야하고, DELETE가 필요합니다 (동일한 링크에서 REST의 레벨 2 참조). 항목의 경우, 단지 속성 일 경우 가장 잘 알고있을 것입니다. 또는 다른 최종포 인 경우 티; 그룹을 검색하는 것과 동일한 호출에서 리턴되도록이를 포함시킬 수도 있습니다.

이점은 클라이언트가 관계 (및 링크) 이름 (물론 자원 구조/속성 외에) 만 알면되지만 서버는 관계 및 리소스 URL을 자유롭게 변경할 수 있습니다 .