HAL + JSON 하이퍼 미디어 유형이 REST의 미디어 유형이 아닙니까?

Question

HAL + JSON 하이퍼 미디어 유형을 RESTful 서비스를 만드는 방식으로 사용할 수 있습니까?

내가 읽은 것으로부터 RESTful API 클라이언트는 특별한 경우로 다른 리소스를 처리 할 필요가 없다. 매체 유형은 대신 어떤 자원이 어떻게 보이는지 설명하는 데 사용해야합니다.

HAL spec

이 예제 제공 : HAL은 + API를 JSON 서빙이 샘플의 클라이언트로

GET /orders 

{ 
    ... 
    "shippedToday": 20, 
    ... 
} 

```

을, 나는 "순서"는이 있는지 알아야 할 것 shippedToday의 속성 클라이언트가 표현의 구문을 이해할 필요가 없어야한다는 제약에 맞지 않는 것 같습니다.

이것은 HAL에 대한 비판이 아닙니다. 문제는 내 (및 다른 사람들의) RESTful API 디자인에 대한 이해를 돕는 것입니다.

Answer 1

HAL + JSON 하이퍼 미디어 유형을 RESTful 서비스를 만드는 방식으로 사용할 수 있습니까?

예.

API에는 게시판 URL이 있어야하며이 경우 / 일 수 있습니다.

사람이 이상적으로 컴퓨터가 사용자의 API를 발견 할 수있는 시작점입니다. HAL specification 자원 표현에 따르면

는

여기서 설명 "_links" 불리는 선택적 속성 포함

그것은 속성 이름 (RFC5988 의해 정의 으로) 링크 간 종류 개체이다 및 값 중입니다 링크 개체 또는 배열 링크 개체.

이러한 링크는 API의 하이퍼 미디어 부분을 나타냅니다. 관계는 IANA - 등록 된 관계 일 수 있거나 자신의 확장 관계를 사용할 수 있습니다.

관계가 모호해서는 안됩니다. 그들의 이름은 고유해야합니다. 그래서 자신의 도메인에있는 URI를 자신의 관계에 대한 이름으로 사용하는 것이 좋습니다. 이 URI는 관계를 나타내는 자원을 식별하며 API 문서, 사용자 또는 기계가 읽을 수있는 관계 문서를 포함합니다.

이 경우 /orders 리소스로의 상태 전이를 설명하는 관계가됩니다. 여기에는 응답에 대한 설명과 설명이 포함되어야하므로 예를 들어. /orders 리소스는 주문 목록을 나타내며 number 유형의 값을 갖는 "shippedToday"라는 속성을가집니다. http://yourdomain.com/docs/rels/orders에서

HTTP/1.1 200 OK 
Content-Type: application/hal+json 

{ 
    "_links": { 
     "self": { "href": "/" }, 
     "http://yourdomain.com/docs/rels/orders": { "href": "/orders" }, 
    } 
} 

는 API 문서가 있어야한다 : 여기

은 GET/HTTP/1.1 요청에 대한 예제 반응이다.