RESTful API 및 junk 쿼리 문자열

Question

RESTful API를 만들고 있는데 'Junk'쿼리 매개 변수를 처리하는 RESTful 방법이 무엇인지 궁금합니다. 현재 반환 된 데이터를 제한 할 수있는 매개 변수가 있습니다.

my.api.com/v1/users?limit=2 

하지만 중 맞춤법 실수를받는 대신하는 경우

my.api.com/v1/users?limti=2 

또는

my.api.com/v1/users?order=asc 

를 구현되지 않은 매개 변수가 나는 오류 JSON 응답을 반환하거나 완전히 무시한다 (즉, 그 응답을 확인하는 사용자의 책임은 정확합니다).

나는 일반적으로 오류 응답 방식을 사용 하겠지만 많은 웹 사이트/서비스가 잘못된 매개 변수를 무시한다는 것을 알게되었습니다.

Answer 1

쿼리 매개 변수는 리소스 식별자의 일부입니다. 쿼리 구성 요소는 경로 구성 요소 (3.3 절)에있는 데이터와 함께하여 URI의 계획의 범위 및 이름 지정 기관 (있는 경우) 내에서 자원을 식별하는 역할을, 비 계층 데이터를 포함 RFC-3986

참조하십시오. 쿼리 구성 요소는 첫 번째 물음표 ("?") 문자로 표시되고 숫자 기호 ("#") 문자 또는 URI의 끝으로 종료됩니다. 이 자원 존재 않습니다

따라서, 중요한 문제는

GET my.api.com/v1/users?limti=2 

에 대한 응답에 물어?

저에게 URI는 클라이언트 오류처럼 보입니다. 귀하의 API 소비자 인 은 엔드 포인트가 내게 원하는 실수가 아닌 임의의 응답을 내게 회신하기보다는 내가 만든 실수 (404가 적합하다고 말함)를 알리는 것을 선호합니다. "Fail fast"는 문제를 훨씬 쉽게 발견합니다.

"네, 그 자원은 존재합니다 - 여기에 그것을 표현하고 있습니다"라고 말하면서 당신이 좋아하는 것을 되돌려 놓는 것만 큼 유효합니다. 그건 도움이되지 않지만 잘못된 것도 아닙니다. 궁극적으로 시스템의 리소스 철자와 실제 맞춤법 오류가 일치하여 맞춤법 오류가 발생하면 결국 끝납니다. 당신의 API는 내가 원하는 것은 my.api.com/v1/suers?limit=2

때 내가 my.api.com/v1/users?limit=2를 요청할 때 할 것입니다 무엇을, 예를 들어, 고려 타협은 (두 세계의 최악이 될 수 있음)에서 실제 자원에 클라이언트를 리디렉션하는 것입니다 귀하의 체계. 예를 들어 order = asc 매개 변수를 무시하려는 경우 해당 표현을 임의로 다시 전달하는 대신 클라이언트를 my.api.com/v1/users으로 리디렉션하는 것이 더 편리 할 수 ​​있습니다.