HATEOAS (REST 아키텍처)에 대한 실제 예 [닫기]

모두가 알 수 있듯이 야생에는 가짜 / 기본 REST-API가 많이 있습니다 (HTTP-API를 구현하고 응용 프로그램의 엔진 상태 그대로의 하이퍼 텍스트로 HTTP-API를 구현하고 REST라고 부릅니다. 받는 로이 T. 필딩의 유명한 호언 장담 먼저 REST 패러다임을 지정한 사람).

상태 전환을위한 관련 애플리케이션 별 미디어 유형 정의와 함께 진정한 하이퍼 텍스트 기반 REST 구현의 실용적인 예를 찾을 수 없었습니다.

그러한 구현에 대해 공개적으로 액세스 가능한 예가 있습니까?

코드를 실행한다는 의미에서 구현 된 것은 아니지만 InfoQ에서 " 커피 한 잔을 얻는 방법 "기사를 정말 좋아합니다 . 스타 벅스에서 커피를 RESTful 프로토콜로 주문하는 과정을 설명합니다. 이는 일반적인 "모든 것이 리소스"인 REST 입문 기사를 넘어 HATEOAS에 중점을 둡니다. 추천.

방법에 대한 일 클라우드 API ? 소개에서 :

API는 URI 공간에서 특정 구조를 전제로하지 않습니다. 시작점은 클라우드 자체를 식별하는 클라우드 서비스 제공자가 제공 한 URI입니다. 클라우드의 표현에는 클라우드의 다른 리소스에 대한 URI와 그에 대해 수행 될 수있는 작업 (예 : 가상 머신 배포 및 시작)에 대한 URI가 포함됩니다.

스토리는 또한 도움이 될 수 있습니다.

Netflix에는 리소스의 일부로 링크를 포함하는 HATEOAS 기반 REST API 가 있습니다.

Roy의 4 번째 요점에서 Sun Cloud API의 RESTfulness가 실제로 해결되지 않았습니까?

REST API는 고정 자원 이름 또는 계층 구조 (클라이언트와 서버의 명백한 결합)를 정의해서는 안됩니다. 서버는 자신의 네임 스페이스를 자유롭게 제어 할 수 있어야합니다. 대신, 서버가 클라이언트에게 HTML 형식 및 URI 템플릿에서 수행되는 것과 같은 적절한 URI를 구성하는 방법을 미디어 유형 및 링크 관계 내에서 해당 명령을 정의하여 지시 할 수 있습니다. [여기서 실패는 클라이언트가 RPC의 기능적 커플 링과 동등한 데이터 지향적 인 도메인 별 표준과 같은 대역 외 정보로 인해 자원 구조를 가정하고 있음을 의미합니다.

예제 1 정의 된 heirachy에서 고정 자원 이름 :

Sun Cloud API에서 : "... VDC의 표현에는 DC를 나타내는 클러스터 표현이 포함되며, 각 클러스터에 VM의 표현이 포함됩니다."

예 2 도메인 별 표준과 같은 대역 외 정보 :

클라우드 자원 필드 "uri"에 대한 "자원 통신 메커니즘"이 GET임을 알기 위해서는 위키 페이지 컨텐츠 (대역 외 정보)가 있어야합니다.

나는 이것이 얼마 전에 요청되었다는 것을 깨달았지만 간단한 예제를 위해 "적절한"REST API 흐름을 시연하는 데 착수했다. REST에 대한 Roy의 규칙을 따르려고했습니다. 아마 도움이 될 수 있습니다 : REST를 사용하는 API 예제