REST API는 최소한 두 가지 방법으로 매개 변수를 가질 수 있습니다.
- 의 URL 경로의 일부로서 (예
/api/resource/parametervalue) - 쿼리 인수로 (예
/api/resource?parameter=value)
가장 좋은 방법은 무엇입니까? 1 사용시기와 2 사용시기에 대한 일반적인 지침이 있습니까?
실제 예 : Twitter는 간격을 지정하기 위해 쿼리 매개 변수를 사용합니다. ( http://api.twitter.com/1/statuses/home_timeline.json?since_id=12345&max_id=54321)
이러한 매개 변수를 URL 경로에 배치하는 것이 더 나은 디자인으로 간주됩니까?
답변
모범 사례가 문서화되어 있으면 아직 찾지 못했습니다. 그러나 URL에 매개 변수를 넣을 위치를 결정할 때 사용하는 몇 가지 지침은 다음과 같습니다.
선택적 매개 변수는 쿼리 문자열에 쉽게 넣는 경향이 있습니다.
매개 변수 값이 기존 리소스와 일치하지 않을 때 404 오류를 반환하려면 경로 세그먼트 매개 변수를 사용하는 경향이 있습니다. 예를 들어 /customer/232, 232는 유효한 고객 ID가 아닙니다.
그러나 빈 목록을 반환하려면 매개 변수를 찾을 수 없을 때 쿼리 문자열 매개 변수를 사용하는 것이 좋습니다. 예 :/contacts?name=dave
매개 변수가 URI 공간의 전체 서브 트리에 영향을주는 경우 경로 세그먼트를 사용하십시오. 예를 들어 언어 매개 변수 /en/document/foo.txt 대/document/foo.txt?language=en
고유 식별자가 쿼리 매개 변수가 아닌 경로 세그먼트에있는 것을 선호합니다.
URI에 대한 공식 규칙은이 RFC 사양에 나와 있습니다 . URI를 매개 변수화하기위한 규칙을 정의하는 또 다른 매우 유용한 RFC 스펙도 있습니다 .
답변
늦은 답변이지만 공유 된 내용, 즉 요청에 여러 유형의 “매개 변수”가 있다는 점에 대한 통찰력을 추가 할 것입니다.이를 고려해야합니다.
- 로케이터-예를 들어 ID 또는 작업 /보기와 같은 리소스 식별자
- 필터-결과 집합을 검색, 정렬 또는 좁히는 매개 변수입니다.
- 상태-예를 들어 세션 식별, API 키, whatevs.
- 내용-예를 들어 저장 될 데이터.
이제 이러한 매개 변수가 들어갈 수있는 다른 위치를 살펴 보겠습니다.
- 요청 헤더 및 쿠키
- URL 쿼리 문자열 ( “GET”vars)
- URL 경로
- 본문 쿼리 문자열 / 멀티 파트 ( “POST”변수)
일반적으로 상태 정보 유형에 따라 헤더 또는 쿠키에 상태를 설정하려고합니다. 우리 모두 이것에 동의 할 수 있다고 생각합니다. 필요한 경우 사용자 정의 http 헤더 (X-My-Header)를 사용하십시오.
마찬가지로 Content는 요청 본문에 하나의 장소 만 있으며 쿼리 문자열 또는 http multipart 및 / 또는 JSON 컨텐츠로 요청 본문에 있습니다. 이는 서버가 컨텐츠를 보낼 때 서버로부터받는 것과 일치합니다. 따라서 당신은 무례하고 다르게 행동해서는 안됩니다.
“id = 5″또는 “action = refresh”또는 “page = 2″와 같은 로케이터는 mysite.com/article/5/page=2각 부분의 의미를 부분적으로 알고있는 곳 (예 : 기사 및 5는 분명히 id가 5) 인 기사 유형의 데이터를 가져오고 추가 매개 변수는 URI의 일부로 지정됩니다. 형식은 page=2이거나 page/2URI의 특정 지점 이후에 “폴더”가 키-값 쌍이라는 것을 알고있는 경우 일 수 있습니다.
필터는 항상 올바른 데이터를 찾는 데 필요한 부분이므로 로케이터가 단독으로 리턴하는 항목의 서브 세트 또는 수정 사항 만 리턴하기 때문에 항상 쿼리 문자열로 이동합니다. mysite.com/article/?query=Obama(서브 세트) 의 검색은 필터이므로 /article/5?order=backwards(수정)도 마찬가지입니다 . 그것이 무엇이라고 불리는 것이 아니라 그것이 무엇인지 생각하십시오!
“view”가 출력 형식을 결정 mysite.com/article/5?view=pdf하면 원하는 리소스를 원점으로 옮기지 않고 찾은 리소스의 수정을 반환하므로 필터 ( )입니다. 대신 기사의 특정 부분을 확인하면 ( mysite.com/article/5/view=summary) 로케이터입니다.
리소스 집합을 좁히는 것은 필터링입니다. 리소스 내에서 특정 항목을 찾는 중입니다 … duh. 서브 세트 필터링은 많은 수의 결과를 리턴 할 수 있습니다 (0까지). 위치는 항상 해당 특정 인스턴스 (있는 경우)를 찾습니다. 수정 필터링은 수정을 제외하고 로케이터와 동일한 데이터를 반환합니다 (수정이 허용되는 경우).
사람들이 물건을 넣을 곳을 잃어 버린 경우 유레카 순간을 사람들에게 줄 수 있기를 바랍니다.
답변
디자인에 따라 다릅니다. REST over HTTP에는 URI에 대한 규칙이 없습니다 (주로 고유 한 것임). 종종 맛과 직관 문제에 관한 것입니다 …
나는 다음과 같은 접근 방식을 취합니다.
- url path-element : 자원 및 해당 path-element는 디렉토리 탐색 및 하위 자원을 형성합니다 (예 : / items / {id}, / users / items). 확실하지 않은 경우 동료에게 순회한다고 생각하고 “다른 디렉토리”에서 가장 가능성이 높은 경로 요소가 올바른 선택이라고 생각하면
- url 매개 변수 : 실제로 순회가없는 경우 (여러 쿼리 매개 변수가있는 검색 리소스가 그 좋은 예입니다)
답변
IMO 매개 변수는 쿼리 인수보다 낫습니다. url은 리소스를 식별하는 데 사용되는 반면, 추가 된 쿼리 매개 변수는 원하는 리소스 부분, 리소스의 상태 등을 지정합니다.
답변
REST 구현에 따라
1) 경로 변수 는 연락처 또는 노래와 같은 자원에 대한 직접 조치에 사용됩니다. 예 :
GET 등 / api / resource / {songid} 또는
GET 등 / api / resource / {contactid}
2) Query perms / argument 는 노래의 메타 데이터와 같은 간접 리소스에 사용됩니다.
답변
유니버스 리소스 로케이터가 제공하는 “컨텍스트”에 대해 데이터를 “포장”하고 게시합니다. 이는 로케이터를위한 # 1을 의미합니다.
# 2로 한계를 극복하십시오. # 1보다 POST를 선호합니다.
참고 : 제한 사항은
POST in POST 매개 변수 내용의 최대 크기가 있습니까?
GET in GET 요청의 길이에 제한이 있습니까? 그리고 _GET에서 URL 매개 변수의 최대 크기
ps 이러한 제한은 클라이언트 기능 (브라우저) 및 서버 (구성)를 기반으로합니다.
답변
URI 표준 에 따르면 경로는 계층 매개 변수에 대한 것이고 쿼리는 비 계층 매개 변수에 대한 것입니다. Ofc. 그것은 당신에게 계층적인 것이 매우 주관적 일 수 있습니다.
여러 URI가 동일한 리소스에 할당 된 상황에서는 식별에 필요한 매개 변수를 경로에, 표현을 작성하는 데 필요한 매개 변수를 쿼리에 넣는 것을 좋아합니다. (이 방법으로 라우팅하기가 더 쉽습니다.)
예를 들면 다음과 같습니다.
/users/123과/users/123?fields="name, age"/users과/users?name="John"&age=30
지도 축소를 위해 다음 접근법을 사용하고 싶습니다.
/users?name="John"&age=30/users/name:John/age:30
따라서 URI를 구성하는 방법은 실제로 귀하와 서버 측 라우터에 달려 있습니다.
참고 :이 매개 변수는 쿼리 매개 변수입니다. 실제로 당신이하고있는 일은 간단한 쿼리 언어를 정의하는 것입니다. 복잡한 쿼리 (과 같은 연산자, 또는보다 큰 연산자 등을 포함)에 따라 기존 쿼리 언어를 사용하는 것이 좋습니다. URI 템플릿 의 기능 은 매우 제한적입니다 …
