[rest] REST API가 정말 RPC입니까? Roy Fielding은 그렇게 생각하는 것 같습니다.

내가 REST에 대해 알고 있다고 생각한 많은 내용은 분명히 잘못된 것입니다. 그리고 저는 혼자가 아닙니다. 이 질문은 긴 도입부가 있지만 정보가 조금 흩어져 있기 때문에 필요한 것 같습니다. 이 주제에 이미 익숙하다면 실제 질문이 끝납니다.

Roy Fielding의 REST API 의 첫 번째 단락은 하이퍼 텍스트 기반이어야합니다. 그는 자신의 작업이 널리 잘못 해석되고 있다고 생각합니다.

HTTP 기반 인터페이스를 REST API로 호출하는 사람들의 수에 실망하고 있습니다. 오늘의 예는 SocialSite REST API 입니다. 이것이 RPC입니다. 그것은 RPC를 비명을 지른다. 디스플레이에 커플 링이 너무 많아서 X 등급을 받아야합니다.

Fielding은 REST API의 여러 속성을 나열합니다. 그들 중 일부는 SO 및 기타 포럼에 대한 일반적인 관행과 일반적인 조언 모두에 위배되는 것 같습니다. 예를 들면 :

• REST API는 초기 URI (책갈피) 및 의도 된 청중에 적합한 표준화 된 미디어 유형 집합 (즉, API를 사용할 수있는 모든 클라이언트가 이해할 것으로 예상 됨) 이외의 사전 지식없이 입력해야합니다. …

• REST API는 고정 리소스 이름 또는 계층 (클라이언트와 서버의 명백한 결합)을 정의해서는 안됩니다. …

• REST API는 리소스를 나타내고 애플리케이션 상태를 구동하는 데 사용되는 미디어 유형을 정의하거나 기존 표준 미디어 유형에 대한 확장 된 관계 이름 및 / 또는 하이퍼 텍스트 사용 마크 업을 정의하는 데 거의 모든 설명 작업을해야합니다. …

“하이퍼 텍스트”라는 개념은 URI 구조 나 HTTP 동사가 의미하는 것보다 훨씬 더 중요한 역할을합니다. “하이퍼 텍스트”는 주석 중 하나에 정의됩니다.

내가 [Fielding]을 하이퍼 텍스트라고 할 때, 정보가 사용자 (또는 자동자)가 선택권을 얻고 작업을 선택하는 어포던스가되도록 정보와 제어를 동시에 표시하는 것을 의미합니다. 하이퍼 미디어는 텍스트가 미디어 스트림 내에 시간적 앵커를 포함한다는 의미의 확장 일뿐입니다. 대부분의 연구자들은 구별을 떨어 뜨 렸습니다.

하이퍼 텍스트는 브라우저에서 HTML 일 필요가 없습니다. 기계는 데이터 형식과 관계 유형을 이해할 때 링크를 따라갈 수 있습니다.

이 시점에서 추측하고 있지만 위의 처음 두 점은 다음과 같은 Foo 리소스에 대한 API 문서가 클라이언트와 서버 간의 긴밀한 결합으로 이어지고 RESTful 시스템에 자리가 없다는 것을 암시하는 것 같습니다.

GET   /foos/{id}  # read a Foo
POST  /foos/{id}  # create a Foo
PUT   /foos/{id}  # update a Foo

대신 에이전트는 예를 들어 / foos에 대한 GET 요청을 발행하여 모든 Foos에 대한 URI를 검색해야합니다. (이러한 URI는 위의 패턴을 따르는 것으로 판명 될 수 있지만 요점 옆에 있습니다.) 응답은 각 항목에 액세스하는 방법과이를 통해 수행 할 수있는 작업을 전달할 수있는 미디어 유형을 사용하여 위의 세 번째 요점을 발생시킵니다. . 따라서 API 문서는 응답에 포함 된 하이퍼 텍스트를 해석하는 방법을 설명하는 데 중점을 두어야합니다.

또한 Foo 리소스에 대한 URI가 요청 될 때마다 응답에는 에이전트가 URI를 통해 연결된 상위 리소스에 액세스하거나 생성 후 조치를 취하는 등 진행 방법을 찾는 데 필요한 모든 정보가 포함됩니다. / 자원 삭제.

전체 시스템의 핵심은 응답이 진행을 위해 에이전트 옵션으로 전달되는 미디어 유형에 포함 된 하이퍼 텍스트로 구성된다는 것입니다. 브라우저가 인간을 위해 작동하는 방식과 다르지 않습니다.

그러나 이것은이 특정 순간에 나의 최선의 추측 일뿐입니다.

Fielding은 그의 토론이 너무 추상적이고 예가 부족하고 전문 용어가 풍부하다는 비판에 응답 한 후속 조치를 게시했습니다 .

다른 사람들은 내가 쓴 내용을 오늘날의 실질적인 관심사에보다 직접적이거나 적용 가능한 방식으로 해독하려고 할 것입니다. 나는 다음 주제로 씨름하거나, 회의를 준비하거나, 다른 표준을 작성하거나, 먼 곳을 여행하거나, 월급을 받았다고 느끼게하는 사소한 일을하기에 너무 바빠서 그렇게하지 않을 것입니다.

따라서 실용적인 사고 방식을 가진 REST 전문가를위한 두 가지 간단한 질문입니다. Fielding이 말하는 내용을 어떻게 해석하고 REST API를 문서화 / 구현할 때이를 어떻게 적용합니까?

편집 :이 질문은 당신이 말하는 것에 대한 이름이 없다면 무언가를 배우는 것이 얼마나 어려울 수 있는지에 대한 예입니다. 이 경우 이름은 “Hypermedia as the Engine of Application State”(HATEOAS)입니다.

---

---

답변