나머지 CRUD 검색

Question

REST WS에서 GET 작업에 문제가 있습니다. Google은 고객을 검색하기위한 몇 가지 필터가있는 프런트 엔드 패널을 보유하고 있습니다.

• 고객 ID (고객 속성)
• 고객 이름 (고객 속성)
• 계좌 번호 (계정 속성)
• 번호판 (차량 등록) ...
: 패널은이 필터를 포함
: 도메인 모델에서

우리는 3 개체가

• 고객
• 계정
• 차량 (계정이 1 개 이상의 차량을 가질 수)

은 어떻게 REST이 seach에 대한 작업을 GET 구현할 수있다 (A 고객은 1 개 이상의 계정을 가질 수)?

GET ..../customers /? name = {name} & accountNum = {accountNumber} & licensePlate = {licensePlate} ?????

accountNumber 및 licensePlate가 고객 리소스에 속하지 않으므로 잘못된 것 같습니다. 기대했던 결과에 이러한 속성이 필요하지 않습니다.

나는 customerFilter와 같은 새 리소스를 만들려고 생각하지만 고객 리소스를 반환해야한다는 것은 의미가 없습니다.

아이디어가 있으십니까?

감사합니다.

Answer 1

귀하가 갖고있는 URL에 어떤 문제도 보이지 않지만 귀하의 우려도 유효합니다.

이 시나리오에서 고려해야 할 것이 있습니다. 이 검색을 통해 API 호출의 응답으로 얻으려고하는 것은 무엇입니까?

응답에 고객 정보 만 포함하려면 검색 조건이 만족되면 /고객이 맞습니다.

고객, 계정 및 차량 정보로 구성된 일반 응답을 원한다면 고객 대신 URL 대신 일반 용어를 사용할 수 있습니다.

이 정보가 도움이되기를 바랍니다. 감사합니다 :)

Answer 2

귀하의 질문에 대한 특정 답변을 가장하지 않습니다. 그러나 나는 GET 방법과 관련된 것을 분명히 할 것이라고 생각한다. 경로를 통해 또는 메시지 본문를 통해 쿼리를 통해 : URI Specification - RFC 3986 및 Http Specification - RFC 7230에 따르면

, 클라이언트에서 서버로 데이터를 전송하는 방법 3 종류가있다.당신은 GET 방식을 사용하는 경우 GET 방식은 성능 거즈 향상을위한 캐시 할 수 있기 때문에

, 메시지 본문을 사용하는 것이 권장되지 않으며 이러한 캐시는 메시지 본문을 무시하거나 요청을 거부 할 수 있습니다 :

을

GET 요청 메시지 내의 페이로드에는 정의 된 의미가 없습니다. GET 요청에서 페이로드 본문을 보내면 일부 기존 구현에서 요청을 거부 할 수 있습니다.

그래서, 당신은 지금 쿼리 또는 경로 선택할 수 있습니다. 모두이 형식으로 URL에 있습니다 이들의 차이점은 무엇

http://example.com/{path1}/{path2}?query1=value1&query2=value2

입니까? RFC 3986 - Path 및 RFC 3986 - Query에있어서

경로 성분이 비 계층 질의 성분 는 (3.4)이 상기 내 자원을 식별하는 역할을 데이터와 함께 보통 계층 형태로 구성 데이터, 그것을 포함 URI 체계 및 명명 기관 (있는 경우)의 범위.

쿼리 구성 요소는 경로 구성 요소 (3.3 절)에 데이터와 함께하여 URI의 계획의 범위와 권한 (있는 경우)를 명명 내 자원을 식별하는 역할을, 비 계층 데이터를 포함합니다.

결론적으로 원하는대로 디자인 할 수 있습니다. 당신은 예를 들어 사용할 수 있습니다

GET .../customers?name={name}&accountNum={accountNumber}&licensePlate={licensePlate}

GET .../customers/{customerId}/

GET .../customers?customerId=12345