LIKE 조건을 사용하여 REST API를 설계하는 방법은 무엇입니까?

Question

나는 REST API를 설계 및 "사람"에 대한 실체가있어 :

GET http://localhost/api/people 

시스템

GET http://localhost/api/people/1 

에있는 모든 사람들의리스트를 돌려줍니다 아이디 1.

가진 사람을 돌려줍니다

GET http://localhost/api/people?forename=john&surname=smith 

어휘와 성이 일치하는 모든 사람을 반환하지만 추가 요구 사항이 있습니다. API 소비자가 forename이 "jo"로 시작하는 모든 사람들을 검색하는 것을 허용하는 가장 깨끗한/모범 사례 방법은 무엇입니까?

좀 API를 이런을 본 적이 :

물결은 "퍼지"일치를 의미

GET http://localhost/api/people?forename=jo~&surname=smith 

. 반면에 나는 완전히 다른 기준으로 구현 된 것을 보았습니다. -soundslike (SOUNDEX 일치의 어떤 종류를 위해), -contains, 내가 -endswith있을 수 있습니다 고려 조금 성가신 것 같다

GET http://localhost/api/people?forename-startswith=jo&surname=smith 

.

누구나 비슷한 기능을 가진 잘 디자인 된 REST API의 더 나은 작동 방식을 경험에서 제안 할 수 있습니까?

Answer 1

AFAIK, 위의 어느 것도 꽤 RESTful은 아닙니다. 둘 다 쿼리를 호출하는 방법 (첫 번째 경우에는 쿼리 패턴, 두 번째 경우에는 쿼리 DSL)에 대한 클라이언트의 부분에 대한 예비 지식을 사용합니다. 두 번째 예에서 실제로 API는 데이터 저장소 주변의 래퍼로만 축소되었습니다. 따라서 API는 서버 도메인을 정의하지 않으며 데이터 제공자입니다. 이는 클라이언트 - 서버 제약의 REST와는 대조적입니다.

다양한 쿼리 기능을 갖춘 데이터 저장소가 필요하면 OData의 알려진 표준을 따르는 것이 좋습니다. OData는 REST로 판매되었지만 많은 REST 헤드에는 문제가 있습니다. 아무튼, 하루가 끝날 때 REST 토론은 일반적으로 분석 마비로 이어질 수 있습니다.

내가이 작업을 수행하는 경우 API를 일반적인 유스 케이스로 제한 할 것이므로 질문 DSL (forename-startswith가 아닌 forenameStartsWith)을 정의하지 않고 두 번째 것과 더 비슷한 것이 좋습니다.

많은 필드와 다양한 조건을 기반으로 쿼리해야하는 경우 OData를 사용합니다.

Answer 2

두 예제 모두 필터링을 위해 쿼리 매개 변수를 사용합니다. 이러한 쿼리 매개 변수를 호출하거나 일부 와일드 카드 구문을 사용하는 것이 중요하지 않다고 생각합니다.

두 방법 모두 똑같이 RESTFul입니다.

Answer 3

IMHO 퍼지 항목이 있거나 -endswith-contains 등이 있으면 상관 없습니다. REST API가 이러한 매개 변수를 쉽게 구문 분석하도록 허용하여 데이터 소스에서 데이터를 가져 오는 함수를 정의 할 수 있다면 중요합니다 (DB 또는 xml 파일 등)

내 경험에 의하면 PHP를 사용하는 경우 SlimFramework은 매우 가볍고 사용하기 쉬운 솔루션입니다.

Answer 4

을 제공하는 OData protocol을 권해드립니다. 당신이 한 일은 괜찮지 만 REST 규칙을 따른다.

그러나 OData 프로토콜은 $expand 매개 변수와 심지어 $filter 매개 변수를 설명합니다. 이 $ 접두사는 "시스템 쿼리 옵션"을 의미하고 다음 URI 쓸 수 있기 때문에 당신은 마지막에 관심이있을 것입니다 : 그것은 당신이 데이터와 같은 SQL을 전달할 수 있습니다

http://services.odata.org/Northwind/Northwind.svc/Customers?$filter=tolower(CompanyName) eq 'foobar' &select=FirstName,LastName&$orderby=Name desc 

, 그것은 좋은 대안이 될 수 있습니다 당신이 묘사 한 것까지 (두 가지 해결책 모두 괜찮습니다. 단지 맛의 문제 일뿐입니다).