웹 브라우저가 쉽게 HatEoAS를 준수합니까?

Question

현재 유명한 blog post에서 REST 아키텍처의 발명가 인 Roy Fielding은 RESTful이라는 용어의 오용을 비판했습니다. 특히 그는 RPC와 REST 인터페이스를 구별했습니다.

내 이해는 RPC 인터페이스에서 모든 상태 변환 방법 (위치 및 의미 포함)은 클라이언트에 알기 쉽지만 REST 인터페이스에서는 클라이언트와 서버가 응용 프로그램 상태 (위치 와의을 의미) 상태 전이의 방법을 설명하고 실제로 가능한 방법은 실행시에 클라이언트에 의해 발견되는 공통의 언어 (사전 구문과 의미있는 공유 미디어 유형이) .

클라이언트 - 서버 상황이 브릿지와 인터페이스하는 스마트 라이트 전구와 같이 전문화되어 있지만 클라이언트 - 서버 관계가 웹 브라우저 및 웹의 관계라고 할 때 특수한 제약이 있음을 알 수 있습니다. 서버, trivially 만족 위의 RESTfulness 제약 아니에요?

이 가능한 서버에 의해 전달 된 자바 스크립트 (이 안식을 깨지 않고 가마로서 예컨대 하드 코딩 된 링크를 포함 할 수있다 그러므로 등) 표현의 일부로서 수행되는 것을 가정한다. 반면에 브라우저 + js 조합이 실제 클라이언트라는 관점을 취한 다음 RESTfulness는 JS 클라이언트의 디자인에 단순한 제한을 부과합니다. 그러나이 견해가 오히려 해석되지 않습니까?

Answer 1

그것은 JS 코드에 사소하지 않은 제약 조건입니다. JS는 자원 표현이 아니라 클라이언트로 간주되어야합니다. 그것은 둘 다라는 것이 사실이지만, 두 가지 다른 관점에서만 가능합니다. JS가 "자원 표현"모자를 쓰면 불활성이고 아무 것도하지 않습니다. 그것이 "REST 클라이언트"모자를 쓰면 더 이상 자원 표현의 일부로 온 것이 중요하지 않습니다.

하드 코딩 된 링크는 유일한 문제가되지 않습니다 : JS 코드가 너무 내부 정보에 문제가 있습니다 사용하여 링크를 구축하는 문자열을 연결. 이러한 REST 위반은 "수정 가능성"의 속성에 영향을 미칩니다. 이는 JS 코드와 서버 구현이 일반적으로 같은 프로젝트의 일부로 개발되었다고 생각할 때 문제가되지 않을 수도 있습니다. URI와 클라이언트 URI 작성 로직을 쉽게 동기화 할 수 있습니다. 그러나 단일 서버 API 구현을 공유하는 자체 JS 클라이언트가있는 여러 개의 응용 프로그램을 보유하고 있다면 어떻게 될까요? URI가 변경되면 많은 클라이언트가 손상됩니다.

JS 코드가 다른 클라이언트와 동일한 규칙을 준수해야합니다 링크는 서버에 의해 제공되는 자원으로부터 와야하고, 의미는 미디어 타입의 공통의 이해에서 와야한다.

구체적인 예

한다고 가정 우리가 같은 책의 집합으로 정의하고, 보이는하는 자원/readinglist/:

가

{ 
    [ 
     { 
     "id":"GoT", 
     }, 
     { 
     "id":"LOTR", 
     }, 
     { 
     "id":"IT", 
     }, 
     ... 
    ] 
} 

JS 코드 목록을 표시하고 사용자가 항목을 클릭하면 JS는 해당 "book"리소스를 가져와 세부 정보를 표시합니다.

GET/읽기 목록/IT

{ 
    "id":"IT", 
    "author":"Stephen. R. R. King" 
} 

이는 소위 "REST"의 API의 모든 너무 일반적인 패턴이다. 하지만 여기서 JS는 컬렉션의 URL에 ID를 추가하여 책을 검색한다는 로직을 JS에 포함해야합니다. 다시 말해, 클라이언트 상태는 대역 외 정보에 의해 결정됩니다.JS 코드 자체가 서버에서 자원으로 제공 되었기 때문에 이것이 대역 외 정보가 아님을 주장 할 수 있습니다. 그러나 JS는 현재 클라이언트 역할을 수행하고 있으므로 분석해야합니다.

는 대조적으로,/readinglist/자원의 표현을 고려 :

{ 
    [ 
     { 
     "id":"GoT", 
     "link:"/books/GoT" 
     }, 
     { 
     "id":"LOTR", 
     "link:"/books/LOTR" 
     }, 
     { 
     "id":"IT", 
     "link:"/books/IT" 
     }, 
     ... 
    ] 
} 

는 이제 JS가 URL을 연결하는 방법을 알 필요가 없습니다. 대신 컬렉션의 표현에서 "링크"URL을 따라 책 리소스를 얻는다는 논리가 있어야합니다. 이것은 다소 복잡합니까? 그것은 거의 같습니다. 주요 차이점은이 접근법을 사용하면 고객의 상태가 합의 된 미디어 유형의 의미에 따라 하이퍼 미디어에 의해 주도된다는 것입니다. 미디어 유형과 처리 규칙이 파악되고 표준화되면 여러 API에서 재사용 할 수 있습니다.