검색이 RESTful 인터페이스에 어떻게 적합합니까?

RESTful 인터페이스를 설계 할 때 요청 유형의 의미는 설계에 필수적으로 간주됩니다.

• GET- 콜렉션 나열 또는 검색 요소
• PUT- 컬렉션 또는 요소 교체
• POST- 콜렉션 또는 요소 작성
• 삭제 -음, 음, 컬렉션 또는 요소 삭제

그러나 이것은 "검색"의 개념을 다루지 않는 것 같습니다.

예를 들어 구직 사이트를 지원하는 웹 서비스 제품군을 설계 할 때 다음 요구 사항이있을 수 있습니다.

• 개별 구인 광고 받기
  • GET 에domain/Job/{id}/
• 구인 광고 만들기
  • POST 로domain/Job/
• 구인 광고 업데이트
  • PUT 에domain/Job/
• 구인 광고 삭제
  • DELETE 에domain/Job/

"Get All Jobs"도 간단합니다.

• GET 에domain/Jobs/

그러나 직업 "검색"은 어떻게이 구조에 속합니까?

당신은 할 수 는 "목록 모음"의 변형의 주장과 같이 구현 :

• GET 에domain/Jobs/

그러나 검색 은 복잡 할 수 있으며 긴 GET 문자열을 생성하는 검색을 생성 할 수 있습니다. 즉, 여기 SO 질문을 참조 하면 약 2000 자보다 긴 GET 문자열을 사용하는 데 문제가 있습니다.

"잡음"예제를 계속하여 패싯 검색에 예제가있을 수 있습니다.

"테크놀로지", "직업 제목", "징계"및 자유 텍스트 키워드, 연령, 위치 및 급여 등의 패싯을 검색 할 수 있습니다.

유동적 인 사용자 인터페이스와 수많은 기술 및 직책을 사용하면 검색에 많은 패싯 선택이 포함될 수 있습니다.

이 예를 작업이 아닌 CV로 조정하면 더 많은 패싯을 가져올 수 있으며, 100 개의 패싯을 선택하거나 각 50 자 길이 인 40 개의 패싯 (예 : 직책, 대학 이름, 고용주 이름).

이 경우 검색 데이터가 올바르게 전송되도록 PUT 또는 POST를 이동하는 것이 바람직 할 수 있습니다. 예 :

• POST 로domain/Jobs/

그러나 의미 적으로 이것은 컬렉션을 만드는 지침입니다.

당신은 수 또한 검색의 생성과이를 표현하는 것입니다 말 :

• POST 로domain/Jobs/Search/

또는 (아래의 불타는 문법에서 제안한 바와 같이)

• POST 로domain/JobSearch/

의미 상 의미가있는 것처럼 보이지만 실제로는 아무것도 만들지 않고 데이터를 요청하고 있습니다.

따라서 의미 상 GET 이지만 GET 이 필요한 것을 지원한다고 보장하지는 않습니다.

따라서 문제는-RESTful 디자인을 가능한 한 충실하게 유지하려고 노력하면서 HTTP의 한계를 지키면서 검색에 가장 적합한 디자인은 무엇입니까?

당신은 잊지 말아야 GET 요청이 일부 우수한있는 장점이 다른 솔루션에 비해을 :

1) GET 요청은 URL 표시 줄에서 복사 할 수 있으며 검색 엔진에 의해 요약되며 "친숙합니다". "친절한"이란 일반적으로 GET 요청이 응용 프로그램 내부의 내용을 수정해서는 안된다는 것을 의미합니다 (idempotent) . 검색의 표준 사례입니다.

2) 이러한 모든 개념은 사용자 및 검색 엔진뿐만 아니라 아키텍처 API 설계 관점 에서도 매우 중요 합니다.

3) 당신이 만드는 경우 해결 방법 과 POST / PUT의 당신은 당신이 지금 생각되지 않는 문제가 발생합니다. 예를 들어 브라우저의 경우 뒤로 탐색 버튼 / 페이지 새로 고침 / 이력. 이것들은 물론 해결 될 수 있지만 다른 해결 방법이 될 것이고, 다른 해결 방법이 될 것입니다 ...

이 모든 것을 고려하면 내 충고 는 다음과 같습니다.

a) 영리한 매개 변수 구조 를 사용 하여 GET 내부에 맞출 수 있어야합니다 . 극단적 인 경우에도 Google 검색 과 같은 전술을 사용하여 많은 매개 변수를 여전히 매우 짧은 URL로 설정할 수 있습니다.

b) JobSearch 와 같은 다른 엔티티 를 애플리케이션에 작성하십시오 . 많은 옵션이 있다고 가정하면 이러한 검색을 저장하고 관리해야 응용 프로그램을 정리할 수 있습니다. JobSearch 오브젝트를 전체 엔티티로 작업 할 수 있습니다. 즉, 더 쉽게 테스트 / 사용할 수 있습니다.

개인적으로 나는 함께 할 얻을 내 모든 발톱과 싸움을 시도 할 것이다 A) 및 모든 희망이 손실 될 때, 나는 옵션에 내 눈에서 눈물이 다시 크롤 것 ) 나 .

TL; DR : 필터링을위한 GET, 검색을위한 POST

컬렉션 검색과 복잡한 검색의 결과를 필터링하는 것을 구별합니다. 내가 사용하는 리트머스 테스트는 기본적으로 필터링 (긍정적, 부정적 또는 범위) 보다 더 많은 것이 필요한 경우 POST가 필요한 더 복잡한 검색이라고 생각합니다.

이것은 무엇이 반환 될지 생각할 때 강화되는 경향이 있습니다. 리소스가 대부분 완전한 수명주기 (PUT, DELETE, GET, collection GET)를 가진 경우에만 GET을 사용 합니다. 일반적으로 컬렉션에서 GET은 해당 컬렉션을 구성하는 REST 리소스 인 URI 목록을 반환합니다. 복잡한 쿼리에서 응답을 구성하기 위해 여러 리소스를 가져 와서 (SQL 조인 생각) URI를 보내지 않고 실제 데이터를 다시 보내려고합니다. 문제는 데이터가 리소스에 표시되지 않으므로 항상 데이터를 반환해야한다는 것입니다. 이것은 POST가 필요한 분명한 경우입니다.

-

시간이 오래 걸리고 원래 게시물이 약간 조잡하여 업데이트 할 것이라고 생각했습니다.

GET은 대부분의 데이터, REST 리소스 모음, 리소스의 구조화 된 데이터, 단일 페이로드 (이미지, 문서 등)를 반환하기위한 직관적 인 선택입니다.

POST는 GET, PUT, DELETE 등에 맞지 않는 모든 것을 포괄하는 방법입니다.

이 시점에서 간단한 검색, 필터링은 GET을 통해 직관적으로 의미가 있다고 생각합니다. 복잡한 검색은 집계 함수, 교차 상관 (결합), 재 포매터 등에 던질 경우 특히 개인 취향에 달려 있습니다. )는 종종 POST 요청 본문으로 더 의미가 있습니다.

또한 API 사용의 경험 측면을 고려합니다. 일반적으로 대부분의 방법을 사용하기 쉽고 직관적으로 만들고 싶습니다. 특히 동일한 API에서 다른 REST 리소스의 동작과 일치하지 않는 경우 POST 및 다른 리소스 URI에 대해 더 유연하고 복잡한 호출을 푸시합니다.

어느 쪽이든, 일관성은 GET에서 검색하든 POST에서 검색하든보다 더 중요합니다.

도움이 되었기를 바랍니다.

REST에서 리소스 정의는 매우 광범위합니다. 그러나 실제로 일부 데이터를 묶고 싶습니다.

• 검색 리소스를 수집 리소스로 생각하면 유용합니다. URI의 검색 가능한 부분이라고도하는 쿼리 매개 변수는 클라이언트가 관심있는 항목으로 리소스를 좁 힙니다.

예를 들어 기본 Google URI는 "인터넷의 모든 사이트에 대한 링크"의 콜렉션 자원을 가리 킵니다. 쿼리 매개 변수는보고자하는 사이트로 범위를 좁 힙니다.

(URI = 범용 자원 식별자, URL = 범용 자원 로케이터. 여기서 친숙한 "http : //"는 URI의 기본 형식입니다. 따라서 URL은 로케이터이지만 REST에서는 자원 식별자로 일반화하는 것이 좋습니다. 그러나 사람들은 그것들을 서로 바꿔서 사용합니다.)

• 예제에서 검색하는 리소스는 작업 모음이므로 검색하는 것이 좋습니다.

GET 사이트 / 작업? type = blah & location = here & etc = etc

(반품) {작업 : [{작업 : ...}]}

그런 다음 추가 또는 프로세스 동사 인 POST를 사용하여 해당 콜렉션에 새 항목을 추가하십시오.

POST 사이트 / 작업

{작업 : ...}

• job각 경우에 객체의 구조는 동일 합니다. 클라이언트는 조회 매개 변수를 사용하여 검색 범위를 좁힌 다음 작업 중 하나에 동일한 형식을 사용하여 새 작업을 POST 할 수있는 작업 콜렉션을 얻을 수 있습니다. 또는 해당 항목 중 하나를 가져 와서 URI로 PUT하여 해당 항목을 업데이트 할 수 있습니다.

• 실제로 길거나 복잡한 쿼리 문자열의 경우 규칙에 따라 POST 요청으로 보낼 수 있습니다. 쿼리 매개 변수를 이름 / 값 쌍 또는 JSON 또는 XML 구조의 중첩 된 개체로 묶어서 요청 본문에 보냅니다. 예를 들어, 쿼리에 여러 이름 / 값 쌍 대신 중첩 된 데이터가있는 경우. POST에 대한 HTTP 스펙은이를 추가 또는 프로세스 동사로 설명합니다. (RES의 허점을 통해 전함을 항해하려면 POST를 사용하십시오.)

그래도이를 대체 계획으로 사용합니다.

당신이 할 때 잃는 것은 a) GET은 nullipotent입니다. 즉, 아무것도 변경하지 않습니다-POST는 아닙니다. 따라서 호출이 실패하면 미들웨어가 결과를 자동으로 재 시도하거나 캐시하지 않으며 2) 본문에 검색 매개 변수를 사용하면 더 이상 URI를 잘라 붙여 넣을 수 없습니다. 즉, URI는 원하는 검색에 대한 특정 식별자가 아닙니다.

"검색"과 "만들기"의 차이점. REST 실습과 일치하는 몇 가지 옵션이 있습니다.

• 작업 대신 작업 검색과 같이 콜렉션 이름에 무언가를 추가하여 URI에서이를 수행 할 수 있습니다. 검색 모음을 별도의 리소스로 취급한다는 의미입니다.

• POST의 의미는 모두 추가 OR 프로세스이므로 페이로드로 검색 본문을 식별 할 수 있습니다. {job : ...} vs. {search : ...}와 같습니다. 적절하게 게시하거나 처리하는 것은 POST 논리에 달려 있습니다.

그것은 거의 디자인 / 구현 환경 설정입니다. 나는 명확한 협약이 있다고 생각하지 않습니다.

이미 준비했듯이 아이디어는 다음에 대한 수집 리소스를 정의하는 것입니다. jobs

사이트 / 작업

검색 범위를 좁히려면 GET + 쿼리 매개 변수로 검색하십시오. 길거나 구조화 된 데이터 쿼리는 POST 본문으로 이동합니다 (별도의 검색 콜렉션 일 수 있음). POST로 작성하여 콜렉션에 추가하십시오. PUT을 사용하여 특정 URI로 업데이트하십시오.

URI와의 스타일 규칙에 따라 하이픈으로 구분 된 단어와 함께 모든 소문자를 사용하는 것이지만 그렇게한다고해서 그런 것은 아닙니다.

(또한, 당신의 질문에서, 당신 이이 길을 먼 길이라는 것이 분명합니다. 나는 그것들을 정렬하기 위해 명시 적으로 종류를 철자했지만, 당신의 질문은 이미 이것의 의미 론적 문제를 대부분 해결했습니다. 답 : 컨벤션과 연습으로 묶었습니다.)

나는 일반적으로 OData 쿼리를 사용하며 GET 호출로 작동하지만 반환되는 속성을 제한하고 필터링 할 수 있습니다.

당신은 같은 토큰을 사용 $select=하고 $filter=그래서 당신은 이런 식으로 뭔가를 보이는 URI로 끝날 것입니다 :

/users?$select=Id,Name$filter=endswith(Name, 'Smith')

또한 사용하여 호출 할 수있는 $skip및 $top및 주문을.

자세한 정보는 OData.org를 확인하십시오 . 사용중인 언어를 지정하지 않았지만 ASP.NET 인 경우 WebApi 플랫폼은 OData 쿼리를 지원합니다. 다른 경우 (PHP 등) 데이터베이스 쿼리로 변환하는 데 사용할 수있는 라이브러리가있을 수 있습니다.

고려해야 할 한 가지 방법은 가능한 쿼리 세트를 수집 리소스로 취급하는 것입니다 (예 :) /jobs/filters.

POST본문에 쿼리 매개 변수가있는이 자원에 대한 요청은 새 자원을 작성하거나 기존의 동등한 필터를 식별하고 해당 ID가 포함 된 URL을 리턴합니다 /jobs/filters/12345.

그런 다음 ID는 작업에 대한 GET 요청에서 사용될 수 있습니다 /jobs?filter=12345. GET필터 리소스에 대한 후속 요청은 필터의 정의를 반환합니다.

이 방법을 사용하면 필터 정의를위한 쿼리 매개 변수 형식에서 벗어날 수있어 복잡한 필터를 정의 할 수있는 강력한 기능을 제공 할 수 있습니다. OR 조건은 쿼리 문자열로는 달성하기 어려운 것으로 생각할 수있는 한 가지 예입니다.

이 접근 방식의 단점은 URL의 가독성을 잃는다는 것입니다 ( GET필터 리소스에 대한 요청을 통해 정의를 검색하여 완화 할 수는 있음 ). 이러한 이유로 /jobs필터 자원 을 지원할 때와 동일하거나 자원 에서 조회 매개 변수의 서브 세트를 지원할 수도 있습니다 . 더 짧은 쿼리에 사용할 수 있습니다. 이 기능이 제공되는 경우, 두 유형의 필터링간에 캐시 가능성을 유지하려면 /jobs자원에서 쿼리 매개 변수를 사용할 때 구현시 내부적으로 필터 자원을 작성 / 재사용하고 의 형식으로 URL을 나타내는 302또는 303상태를 리턴해야합니다 /jobs?filter=12345.

이것은 오래된 대답이지만 여전히 토론에 약간 기여할 수 있습니다. 나는 종종 REST, RESTful 및 Architecture에 대한 오해를 자주 관찰했습니다. RESTful은 검색을 구축하지 않는 것에 대해 언급하지 않았으며 RESTful에는 아키텍처에 대해 아무것도 없으며 디자인 원칙 또는 기준 세트입니다.

검색을 더 잘 설명하려면 특히 아키텍처에 대해 이야기해야하며 더 적합한 아키텍처는 ROA (Resource Oriented Architecture)입니다.

RESTful에는 디자인 할 원칙이 있습니다. idempotent는 일부 답변을 읽을 때 결과가 변경되지 않는다는 것을 의미하지 않으며 독립적 요청의 결과는 실행 횟수에 의존하지 않습니다. 변경 가능, RESTful Api가 제공하는 일부 데이터로 데이터베이스에 지속적으로 데이터를 제공하는 데이터베이스를 지속적으로 업데이트한다고 가정 해보십시오. 동일한 GET을 실행하면 결과가 변경 될 수 있지만 실행 횟수에 의존하지 않습니다. 내가 세상을 얼릴 수 있다면 그것은 다른 결과를 초래하는 자원을 요청할 때 상태, 변형, 서비스 내부에 아무것도 없다는 것을 의미합니다.

정의에 따르면 리소스는 그 자체로 사물로 참조되어야하는 모든 것입니다.

리소스 지향 아키텍처 (간단하게하기 위해 지금부터 ROA라고하자)에서 우리는 많은 것들이 될 수있는 리소스에 중점을 둡니다.

• 문서의 버전
• 문서의 마지막 업데이트 버전
• 검색 결과
• 객체 목록
• 전자 상거래에서 구매 한 첫 번째 기사

리소스 측면에서 독창적 인 것은 추가 가능성 입니다. 즉 URI 가 하나만 있음을 의미합니다.

그런 식으로 검색 은 ROA를 고려하여 RESTful에 완벽하게 적합합니다 . 검색이 일반 검색이고 아무것도 변경하지 않는다고 가정하기 때문에 GET을 사용해야합니다. 따라서 dem 등원입니다 (추가 된 새로운 요소에 따라 다른 항목을 반환하더라도). ROA가 아닌 RESTful을 고수 할 수 있기 때문에 혼란이 있습니다 .ROA의 주소 지정 원칙을 사용하지 않기 때문에 검색을 만들고 동일한 매개 변수로 다른 것을 반환하는 패턴을 따를 수 있음을 의미합니다. 방법 것입니다? 본문이나 헤더에 검색 필터를 보내면 리소스를 ADDRESSABLE 할 수 없습니다.

W3 원본 문서에서 정확히 무엇이고 URI의 원리를 찾을 수 있습니다.

https://www.w3.org/DesignIssues/Axioms

이 아키텍처의 모든 URL은 자기 설명 적이어야합니다. URI의 모든 것을 처리하기 위해 원칙을 따르는 경우 필요합니다. / (슬래시)를 사용하여 필요한 항목이나 쿼리 매개 변수를 구분할 수 있습니다. 우리는 그것에 제한이 있다는 것을 알고 있지만 이것이 아키텍처 패턴입니다.

RESTful의 ROA 패턴에 따라 검색은 다른 리소스보다 크지 않으며, 유일한 차이점은 리소스는 개체 자체와 직접적인 관계가 아니라 계산에서 나온 것입니다. 원칙에 따라 다음 패턴을 기반으로 간단한 산술 계산 서비스를 처리하고 얻을 수있었습니다.

http://myapi.com/sum/1/2

합계 1과 2를 수정할 수는 있지만 계산 결과가 독특하고 다룰 수 있습니다. 동일한 매개 변수를 사용하여 호출 할 때마다 서비스에서 동일하고 아무런 변화가 없습니다. resouce / sum / 1 / 2 및 / substract / 5 / 4는 원칙을 완벽하게 준수합니다.

하나의 URI에 대해 항상 동일한 결과 (표현)를 리턴하는 정적 콜렉션이있는 경우 GET은 정상입니다. 또한 이러한 표현을 생성하는 데이터는 절대 변경되지 않습니다. 소스는 읽기 전용 데이터베이스입니다.

GET이 하나의 동일한 URI에 대해 다른 결과를 리턴하게 하면 dem 등성 / 안전성 및 CoolURI 원칙을 위반 하므로 RESTful하지 않습니다 . dem 등원 동사를 데이터베이스에 쓸 수는 있지만 표현에 영향을 미치지 않아야합니다.

공통 검색은 결과에 대한 참조를 리턴하는 POST 요청으로 시작합니다. 결과를 생성합니다 (새롭고 후속 GET으로 페치 할 수 있음). 물론이 결과는 계층적일 수 있으며 (GET 할 수있는 URI를 사용하는 추가 참조) 애플리케이션에 적합한 경우 이전 검색의 요소를 재사용 할 수 있습니다.

그건 그렇고, 나는 사람들이 다르게 행동한다는 것을 알고 있습니다. REST를 위반하는 것이 얼마나 편리한 지 설명 할 필요가 없습니다.