클라이언트가 어쨌든 그것을 사용하기에 충분하지 않은 경우 REST API에서 '검색 가능성'이 필요한 이유는 무엇입니까?

내가 본 다양한 대화와 REST에서 스캔 한 튜토리얼은 '발견 성'이라는 것을 강조하는 것 같습니다. 제한적인 이해로,이 용어는 고객이 가서 할 http://URL수있는 일의 목록을 자동으로 얻을 수 있어야한다는 의미 인 것 같습니다 .

내가 이해하는 데 어려움을 겪고있는 것은 '소프트웨어 클라이언트'가 인간이 아니라는 것입니다. 제공된 링크로 정확히 무엇을해야하는지 이해하기위한 직관적 인 지식이없는 프로그램 일뿐입니다. 오직 사람들 만이 웹 사이트를 방문하여 제시된 텍스트와 링크를 이해하고 그에 따라 행동 할 수 있습니다.

클라이언트의 개발자가 실제로 제시된 자원을 실험하지 않는 한, 그러한 발견 가능한 URL에 액세스하는 클라이언트 코드가 실제로 어떤 것도 할 수없는 경우, 발견의 요점은 무엇입니까? 이것은 다른 방향에서 문서 매뉴얼에 사용 가능한 기능 세트를 정의하는 것과 똑같은 것처럼 보이며 실제로 개발자를 위해 더 많은 작업이 필요합니다. 실제 REST 자원 외부의 문서에서 수행 할 수있는 사전 정의의 두 번째 방법이 왜 열등한 것으로 간주됩니까?

검색 가능성은 관련이 없지만 검색 가능성을 허용하는 링크는 더 많은 목적을 제공합니다. 내 생각에 가장 중요한 것은 클라이언트에 대한 응답으로 전체 URI를 제공한다는 것은 클라이언트가 URI를 "구성"할 필요가 없다는 것을 의미합니다. 즉, 어떤 클라이언트도 URI의 구조에 대한 지식이 필요하지 않습니다. 그리고 서버 개발자는 URI 구성표에 구식 방법을 계속 사용하는 기존 클라이언트를 고려할 필요가 없으므로 URI 구성표가 필요할 때마다 URI 구성표를 변경할 수 있습니다.

"클라이언트"는이를 사용하기에 충분하지는 않지만 클라이언트 사용자는 사용할 수 있습니다. 클라이언트는 결국 웹 브라우저처럼 간단한 것일 수 있습니다. 발견 가능성은 사람들이 API를 배우고 사용할 수있게하는 것 입니다.

예를 들어 Jenkins (CI 서버)에는 REST와 유사한 인터페이스가 있습니다. 아무 페이지로나 가서 URL에 "/ api"를 붙이면 할 수있는 모든 것을 설명하는 페이지가 나타납니다. API 학습을 간단하게 만듭니다. 예를 들어 http://ci.jruby.org 는 jruby의 jenkins 서버로 이동하고 http://ci.jruby.org/api 는 해당 특정 페이지의 api로 이동합니다.

이해하기 매우 어려운 문서가 포함 된 API로 작업하는 데 약간의 기쁨이있었습니다.

서버에서 실제 회신을 받으면 설명서와 서버 회신을 비교하고이를 사용하여 설명서를 해독 할 수있었습니다 (그렇습니다. 올바른 용어로 해독했습니다). 문제는 사양에 따라 정확하지 않은 서버로 요청을 보낸 경우 오류가 발생하고 읽을 수없는 설명서를 사용하여 올바른 요청을 보내는 방법을 알아내는 것이 불가능하다는 것입니다. 서로 동의하지 않았고 아마도 API 자체에 동의하지 않은 다른 버전의 API 문서도있었습니다. 도움이되지 못했습니다.

서버에 보낼 수있는 명령이 하나 있고 가능한 모든 명령 목록과 명령을 정확히 보내는 방법을 반환하면 매우 도움이 될 것입니다. 검색 가능성은 클라이언트뿐 아니라 소프트웨어 개발자에게도 유용합니다.

참고 : 나는 그 주제에 대해 전문가가 아니지만 몇 년 전에 사람들의 "REST"해석에 대한 다른 뉘앙스를 조정하려고 시도하는 비슷한 과정을 거쳤습니다. 시각.

필자가 이해하기에 이것은 Roy Fielding의 하이퍼 미디어에서 "HATEOAS"라는 애플리케이션 상태 엔진으로 시작되며, 이는 "시맨틱 웹"의 아이디어를 가능하게합니다.

그래서 ... 기본적으로, 다시 한 번 이해하면 RESTful 응용 프로그램을 기본적으로 자체 설명하여 소비자가 콘텐츠 / 기능을 소비하기 위해 공식 계약에 대한 사전 지식이 필요하지 않도록합니다. 기본 루트 엔드 포인트에서 참여한 다음 소비자가 상호 작용할 때 앱이 제공하는 상황에 맞는 링크를 걸을 수 있습니다. 물론 소비자는 개인 또는 전신 에이전트 일 수있다.

소비자가 잘 알려진 계약에 따라 사전에 알고 알아야하는 CRUD 작업에 매핑 된 예쁜 URL에 "REST"를 사용하는 경우 Roy Fielding은 진정으로 RESTful 한 것으로 간주하지 않습니다.

REST 풍미가있는 RPC 서비스 설정은 더 정교하지 않은 RPC 모델에 비해 유용하지 않고 제한적 / 통제 된 사용에 적합 할 수는 없지만, 강인한 사람들은 코를 내려다보고 타락한 것으로 간주합니다. / 실제로 REST가 아닙니다.